--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-16 06:55 ---
This looks wrong. The code in expand_one_stack_var_at (before dynamic stack
realignment) made perfect sense, if we gave a bigger alignment to some variable
(e.g. automatic array), it is useful to tell the expanders t
--- Comment #10 from wilson at codesourcery dot com 2010-06-16 06:30
---
Subject: Re: suboptimal MIPS widening multiply accumulate
On Wed, 2010-06-09 at 20:21 +, bernds at gcc dot gnu dot org wrote:
> What do you think? Please let me know what your MIPS tests turned up.
I'm look
--- Comment #3 from amodra at gmail dot com 2010-06-16 05:59 ---
Confirmed on powerpc-linux. check_fa tail calls check_fa_mid, ignoring the
fact that check_fa_mid is passed the address of a check_fa local var.
1510 :
1510: 94 21 ff e0 stwur1,-32(r1)
1514:
--- Comment #14 from amodra at gcc dot gnu dot org 2010-06-16 04:23 ---
Subject: Bug 44507
Author: amodra
Date: Wed Jun 16 04:23:05 2010
New Revision: 160822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160822
Log:
PR tree-optimization/44507
* gcc.dg/vect/pr445
--- Comment #13 from amodra at gcc dot gnu dot org 2010-06-16 04:22 ---
Subject: Bug 44507
Author: amodra
Date: Wed Jun 16 04:22:36 2010
New Revision: 160821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160821
Log:
PR tree-optimization/44507
* gcc.dg/vect/pr445
--- Comment #12 from amodra at gmail dot com 2010-06-16 03:14 ---
testsuite/gcc.dg/vect/pr44507.c is invalid on LP64. This:
curVal = *((unsigned long *)(&pArray[index]));
loads 8 bytes, ie. the last time around the loop this loads 4 bytes past the
end of the array. On big-endian
--- Comment #14 from danglin at gcc dot gnu dot org 2010-06-16 02:44
---
I think the setting of reg:DI 2374 from reg:DI 2349 is incorrect. Testing
fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
--- Comment #13 from danglin at gcc dot gnu dot org 2010-06-16 01:27
---
The flag for reg:DI 2349 is copied from:
Breakpoint 7, set_reg_attrs_from_value (reg=0x83fffd4c0420,
x=0x83fffd976c40) at ../../gcc/gcc/emit-rtl.c:975
975 if (HARD_REGISTER_P (reg))
(gdb) p debu
--- Comment #2 from tony at bakeyournoodle dot com 2010-06-16 01:03 ---
Created an attachment (id=20924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20924&action=view)
Proposed fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553
--- Comment #1 from tony at bakeyournoodle dot com 2010-06-16 01:02 ---
Created an attachment (id=20923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20923&action=view)
Buildlogs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44553
When trying to cross compile a stage1 (I believe that is the correct
terminology) compiler I get the following error.
---
/home/tony/buildall/ia64/gcc0/./gcc/xgcc -B/home/tony/buildall/ia64/gcc0/./gcc/
-B/opt/cross/gcc-4.4.4-nolibc/ia64-linux//ia64-linux/bin/
-B/opt/cross/gcc-4.4.4-nolibc/ia64-lin
--- Comment #12 from danglin at gcc dot gnu dot org 2010-06-16 01:01
---
The REG_POINTER flag for reg:DI 274 is copied from reg:DI 2374 in pa.c.
The flag for reg:DI 2374 is in turn copied from reg:DI 2349 in pa.c.
The flag for reg:DI 2349 is set here:
(gdb) p debug_rtx (reg)
--- Comment #5 from dpovey at gmail dot com 2010-06-15 23:22 ---
OK thanks guys.
--
dpovey at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-15 23:21 ---
N.B. it's not necessarily a mistake. If an explicit specialization is defined
in another translation unit then the implicit instantiation of the primary
template must be suppressed, or you get multiple definitions and a
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-15 23:18 ---
It's true that your specialization is only a declaration, but this would be a
definition too:
template<>
const int MyTraits::kValue = 1;
It's not true that the declaration has no purpose, it tells the compiler there
i
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|trivial |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-15 23:13
---
For the record, neither ICC nor SunStudio warn. I seem to remember that in the
past people often commented that it's pretty tough to produce warnings for this
kind of mistake.
--
http://gcc.gnu.org/bugzill
--- Comment #1 from dpovey at gmail dot com 2010-06-15 22:47 ---
Sorry, I made a mistake in the last line: I meant "Definitely not meaningful
for a const member."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44552
If you compile the following code:
template class MyTraits {
public:
static const T kValue = 0;
};
template<>
const int MyTraits::kValue; // define it.
int main(){
const void * a = &(MyTraits::kValue);
}
g++ will issue no warnings but give linking errors. The statement
template<> const in
Consider the following testcase:
#include
static inline __m256i __attribute__((always_inline))
my_add(__m256i a0, __m256i b0)
{
__m128i a1 = _mm256_extractf128_si256(a0, 1);
__m128i b1 = _mm256_extractf128_si256(b0, 1);
__m256i r =
_mm256_castsi128_si256(_mm_add_epi32(_mm256_castsi2
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-15 22:24 ---
> but it is an explicit specialization of the *definition* of the variable
No it is a specialization of the declaration. There are only specialization of
declarations; never definitions. Re-read the link you gave
--- Comment #2 from dpovey at gmail dot com 2010-06-15 22:19 ---
I don't agree with you that this is not a bug, although I do agree that I could
have coded it differently.
Look at
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref
I'm noticing wrong filenames and line numbers on error messages when combining
optimised build with c++0x and precompiled headers. Here is a minimal test
case:
All.h:
#include
test.h:
#include "All.h"
test.cpp:
#include "test.h"
Test::Test()
{
}
g++ -std=gnu++0x -O3 All.h
g++ -std=gnu++0x -O3
--- Comment #15 from tromey at gcc dot gnu dot org 2010-06-15 21:51 ---
I think we've decided not to pursue this route.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 21:05 ---
Dominique, thanks for reporting this. I can confirm the error you're seeing and
I already see what's wrong: In 'match_procedure_in_type' the handling of the
gfc_typebound_proc structures is not correct (each procedure
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-06-15
20:34 ---
(In reply to comment #3)
> Or use multiple alternatives feature for inline assembly constraints to emit
> either VMOV or VLD1?
Well, this kind of works :) But is very ugly and fragile:
/**
--- Comment #3 from siarhei dot siamashka at gmail dot com 2010-06-15
20:14 ---
The whole point of submitting this PR was to find an efficient way to use NEON
instructions to operate on any arbitrary scalar floating point values in order
to overcome Cortex-A8 VFP Lite inherent slowness
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-15 20:10
---
(In reply to comment #2)
>> Try to change that into a "print *, atan(1.0, i/10.0) -atan2(1.0, i/10.)"
>> and see what it outputs.
>
> Only changing the first line, I get
>
> -4.35482832E-08
> Abort
Changing
After the fix for pr40117 with r160646, the following code (borrowed from
somewhere)
MODULE rational_numbers
IMPLICIT NONE
PRIVATE
TYPE,PUBLIC :: rational
PRIVATE
INTEGER n,d
CONTAINS
! ordinary type-bound procedure
PROCEDURE :: real => rat_to_real
! specific type-bo
--- Comment #12 from janus at gcc dot gnu dot org 2010-06-15 19:41 ---
(In reply to comment #11)
> This gives me a segfault ICE.
... with the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50
"
--- Comment #11 from janus at gcc dot gnu dot org 2010-06-15 19:38 ---
Here is a reduced test case, based on comment #0:
module grid_module
implicit none
type grid
end type
type field
type(grid) :: mesh
end type
contains
real function return_x(this)
class(grid) :: t
--- Comment #4 from spop at gcc dot gnu dot org 2010-06-15 19:13 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from spop at gcc dot gnu dot org 2010-06-15 19:12 ---
Subject: Bug 44391
Author: spop
Date: Tue Jun 15 19:11:59 2010
New Revision: 160803
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160803
Log:
Fix PR44391: use size_one_node for pointer types.
2010-06-15 Seba
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-15 19:08 ---
Comment #1 is fixed by r160622, but the original test case still does not work
(hangs in some kind of infinite loop for me, at r160801 on
x86_64-unknown-linux-gnu).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-15 19:00 ---
No you just specialized the declaration.
You want:
template
const T MyTraits::kValue; // define it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-06-15 19:00
---
.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-06-15 18:57
---
Subject: Bug 42461
Author: ebotcazou
Date: Tue Jun 15 18:56:59 2010
New Revision: 160802
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160802
Log:
Backport from mainline
2010-06-09 Eric
Complete code is below [just a few lines]. Note-- bug goes away when I
initialize the variable outside the class, not inside.
qpo...@merlin: ~$ cat temp.cc
template class MyTraits {
public:
static const T kValue = 0;
};
template<>
const int MyTraits::kValue; // define it.
int main(){
cons
GCC with -Wuninitialized enabled and -On where n>= 1 will report falsely that a
variable is uninitialized despite having sufficient information to determine
that the variable must necessarily be initialized.
The erroneous warning is:
In function ‘main’:
warning: ‘n’ may be used uninitialized in th
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-15 18:42 ---
Fixed with r160801. Remaining problems are tracked by PR 44541.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 18:40 ---
(In reply to comment #0)
> Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature)
For the MOLD problem we already have a test case in allocate_alloc_opt_10.f90
(which is put behind comments right now, but should
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-15 18:35 ---
Subject: Bug 43388
Author: janus
Date: Tue Jun 15 18:33:58 2010
New Revision: 160801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160801
Log:
2010-06-15 Janus Weil
PR fortran/43388
* gfor
--- Comment #6 from ubizjak at gmail dot com 2010-06-15 18:16 ---
(In reply to comment #5)
> bbro pass is blindly changing:
Ooops, scrap this. Post-reload splitter is splitting in a wrong way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
--- Comment #5 from ubizjak at gmail dot com 2010-06-15 18:09 ---
Confirmed.
bbro pass is blindly changing:
(jump_insn 55 57 23 2 pr44546.c:10 (set (pc)
(if_then_else (unle (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:SI 28)
(pc))) 5
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|4.5 ICE in extract_insn, at |[4.5/4.6 Regression] ICE in
|recog.c:2103 with -ffa
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-15 18:07 ---
It is caused by revision 149035:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-15 17:55 ---
We seem to be folding the virtual call to the wrong method. I'm
investigating...
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from hjl dot tools at gmail dot com 2010-06-15 17:25
---
Created an attachment (id=20922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20922&action=view)
A new patch
Fix typo and update comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-15 17:20
---
Created an attachment (id=20921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20921&action=view)
An updated patch
I don't see why expand_one_stack_var_at should compute alignment
when its callers know what
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-15 17:13
---
Created an attachment (id=20920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20920&action=view)
A patch to use alignment
If we already know the alignment we need, why not use it? Here is
a patch does it.
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 17:12 ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159362
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 16:57 ---
Should be fixed now, sorry.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2010-06-15 16:45 ---
Re: #c4 - !really_expand never occur when !optimize and for optimize they
are called IMHO way too early (during inlining etc.).
Re: #c8 - the testcases were meant for the given range of svn revs of trunk to
show the i
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-15 16:32 ---
Subject: Bug 44544
Author: jakub
Date: Tue Jun 15 16:32:24 2010
New Revision: 160798
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160798
Log:
PR bootstrap/44544
Backport from mainline
--- Comment #3 from chexum at gmail dot com 2010-06-15 16:31 ---
/* minimal source showing (hopefully) the same ICE */
typedef struct { float *ewgts; } vtx_data;
extern int whatever(vtx_data *);
float *compute_apsp_artifical_weights_packed (vtx_data * graph, int n)
{
float *weights;
--- Comment #2 from chexum at gmail dot com 2010-06-15 16:26 ---
Created an attachment (id=20919)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20919&action=view)
Original compilation log with -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
--- Comment #1 from chexum at gmail dot com 2010-06-15 16:26 ---
Created an attachment (id=20918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20918&action=view)
Original preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
libtool: compile: gcc -v -save-temps -DHAVE_CONFIG_H -I. -I../.. -I../..
-I../../lib/common -I../../lib/gvc -I../../lib/pack -I../../lib/ortho
-I../../lib/pathplan -I../../lib/graph -I../../lib/sparse -I../../lib/rbtree
-I../../lib/sfdpgen -I../../lib/cdt -Os -Wall -D_LARGEFILE_SOURCE
-D_FILE_OFFS
--- Comment #1 from gxgjyyozme at zrmshffbt dot mine dot nu 2010-06-15
16:22 ---
Created an attachment (id=20917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20917&action=view)
Instance of source code which causes crash.
from geany/scintilla
--
http://gcc.gnu.org/bugzilla/
A combination of options can yield the error:
internal compiler error: in remove_unreachable_handlers, at tree-eh.c
To produce the error, g++ is invoked thus:
g++ -c -pipe --trapv --non-call-exceptions --stack-check -O2
Aside from -pipe and -O2, which can be further decomposed, the options are th
--- Comment #2 from spop at gcc dot gnu dot org 2010-06-15 16:19 ---
Patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01519.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44391
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-15 15:39 ---
(In reply to comment #7)
> Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
> but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
>
I set the breakpoint at expand_one_stack_v
Build passed last with 160755, first failure 160784 as follows, most likely for
all targets:
/bin/sh /tmp/hpautotest-gcc44/gcc/gcc/../move-if-change tmp-gcov-iov.h
gcov-iov.h
echo timestamp > s-iov
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -W
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-15 15:28 ---
This is due to C's complex declarator syntax, where the "*" is associated with
the identifier "f" not the return type. You would need to say:
char static *f()
--
redi at gcc dot gnu dot org changed:
Wh
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-15 15:08 ---
Unfortunately I don't see this happening on the x86_64-linux ->
arm-linux-gnueabi cross compiler I built for myself. The generated
assembly has all four elements in the initialization of CSWTCH.2 and
the intermediat
Hello,
consider the following two declarations, which compile fine
static char f();
static char* f();
Then, if I move the 'static' keyword, like so:
char static f();
char* static f();
The first one still compiles, but the second one fails like this:
error.c:1: error: expected identifier or '(
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 ---
Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-15 14:46 ---
I watched crtl->stack_alignment_estimated in gdb
with the testcase in comment #2. I didn't see it
set to 256.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
Under
gcc version 4.3.2 (Debian 4.3.2-1.1)
and
cc version 4.3.4 20090804 (release) 1 (GCC) Target: i686-pc-cygwin
i obtained same result after testing features from tutorial
http://www.cplusplus.com/doc/tutorial/typecasting/ there :
http://old.nabble.com/file/p28892128/tutor.cpp tutor.cpp
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-15
14:09 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
> --- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:51
> ---
>> if(atan(1.0, i/10.0) -atan2(1.0,
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 ---
Oh, and yes, I agree that in expand_one_stack_var_at (only called when
really_expand == true) we should limit align to $something. I'm just not
sure what $something is. crtl->stack_alignment_estimated is not really it
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 ---
Can you try to instead do the stack-estimation only when really_expand is
false? The issue is, we see all variables (or we _should_ see) exactly twice,
once for estimation, once for generating the DECL_RTL. The code w
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-15
13:15 ---
Subject: Re: [4.5/4.6 Regression] FAIL:
gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
Attached .i.
Dave
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-15
13:1
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 12:53 ---
Created an attachment (id=20914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20914&action=view)
gcc46-pr44542.patch
For the "don't use changed DECL_ALIGN for stack estimation after
expand_one_stack_var_at has
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-15 12:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 12:27 ---
Subject: Bug 44536
Author: jakub
Date: Tue Jun 15 12:27:01 2010
New Revision: 160783
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160783
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 12:17 ---
Subject: Bug 44536
Author: jakub
Date: Tue Jun 15 12:17:16 2010
New Revision: 160780
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160780
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-15 12:15 ---
Subject: Bug 44536
Author: jakub
Date: Tue Jun 15 12:15:26 2010
New Revision: 160779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160779
Log:
PR fortran/44536
* langhooks.h (struct lang_hooks
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 11:36 ---
I don't have any wrong-code testcases.
__attribute__((noinline, noclone)) void
f (long x)
{
long a, b, c, d;
asm ("");
__builtin_alloca (1);
}
int
main (void)
{
f (1234567890);
return 0;
}
shows the same is
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 ---
We have a slightly problematic ordering issue here. Here's what I
think should be made the case:
DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
(and for calculating offsets from stack-ptr
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-06-15 11:09
---
Subject: Bug 44464
Author: jamborm
Date: Tue Jun 15 11:09:12 2010
New Revision: 160777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160777
Log:
2010-06-15 Martin Jambor
PR lto/44464
*
On say -O0:
void foo (long x)
{
long a, b, c, d;
__builtin_alloca (1);
}
some of the variables get much higher DECL_ALIGN than they in the end really
have. I don't have a testcase which shows miscompilation on the trunk, still
it seems to be a latent bug. IMHO it should instead set DECL_ALIG
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-06-15
10:34 ---
Created an attachment (id=20913)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20913&action=view)
a fixed testcase
A fixed testcase attached.
The main problem here is that denormals are not handled i
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-06-15 10:05
---
This is now fixed on both the trunk and the 4.5 branch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-15 10:04
---
This is now fixed on both the trunk and the 4.5 branch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-06-15 10:03
---
Subject: Bug 44258
Author: jamborm
Date: Tue Jun 15 10:03:35 2010
New Revision: 160776
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160776
Log:
2010-06-15 Martin Jambor
PR tree-optimization/4
--- Comment #5 from laurent at guerby dot net 2010-06-15 09:58 ---
Reverting Steven patch with your fix is enough to get back bootstrap:
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01497.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-06-15 09:48
---
Subject: Bug 44423
Author: jamborm
Date: Tue Jun 15 09:48:39 2010
New Revision: 160775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160775
Log:
2010-06-15 Martin Jambor
PR tree-optimization/4
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature), but it also
applies to polymorphic variables with INTENT(OUT) (i.e. to F2003).
In either cases, a potentially existing default initializer of the *effective
type* needs to be applied. That means that this data has to be available in the
--- Comment #2 from zsojka at seznam dot cz 2010-06-15 07:28 ---
Created an attachment (id=20912)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20912&action=view)
reduced testcase, -fkeep-inline-functions is not needed there
As the original testcase, this ICEs only in 4.6 too:
$ /
92 matches
Mail list logo
