--- Comment #1 from schwab at linux-m68k dot org 2010-08-18 08:19 ---
That's how it is defined by the respective ABIs. On i386-linux a struct field
has at most 32-bit alignment. Add explicit padding or compile with
-malign-double if you want to be compatible to the mingw32 ABI, but
--- Comment #7 from iains at gcc dot gnu dot org 2010-08-18 08:21 ---
Subject: Bug 42487
Author: iains
Date: Wed Aug 18 08:21:43 2010
New Revision: 163326
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163326
Log:
PR debug/42487
* lib/target-supports.exp
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-18 08:45 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45316
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-18 08:55 ---
Doing binary search shouldn't be too hard, just build two separate kernel
trees, one with the problematic patch applied, one without, with make V=1
output put into some log file in each case.
Then just start with the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-18 09:16 ---
With 4.5.1 I get (checking enabled)
VM.cpp: In member function 'gnash::VM::RNG gnash::VM::randomNumberGenerator()
const':
VM.cpp:126:1: error: statement marked for throw in middle of block
# .MEM_19 = VDEF .MEM_18
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:34
---
Subject: Bug 42575
Author: mkuvyrkov
Date: Wed Aug 18 10:34:02 2010
New Revision: 163334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163334
Log:
gcc/
PR rtl-optimization/42575
*
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:43
---
Bernd did all the heavy lifting for this patch. The above patch fixes the last
piece of the problem -- extra move when compiling for ARMv7-A.
--
mkuvyrkov at gcc dot gnu dot org changed:
What
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-18 10:50 ---
So the scheduler uses cselib to get a better view of the address, but cselib
doesn't actually give a better address. And the solution is to just give up in
that case? It seems to me that if cselib doesn't give a
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-18 12:32 ---
This is broken for more than month, by a change which didn't fix any bug, nor
improved code generation nor compilation time; I'd say DECL_CHAIN should drop
the DECL_MINIMAL_CHECK test unless this is resolved soon,
--- Comment #6 from qiyao at gcc dot gnu dot org 2010-08-18 12:34 ---
Subject: Bug 45094
Author: qiyao
Date: Wed Aug 18 12:33:43 2010
New Revision: 163338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163338
Log:
gcc/
PR target/45094
* config/arm/arm.c
--- Comment #11 from hjl at gcc dot gnu dot org 2010-08-18 13:36 ---
Subject: Bug 45292
Author: hjl
Date: Wed Aug 18 13:35:46 2010
New Revision: 163339
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163339
Log:
Expand pending pops before trying the optab.
2010-08-18 Paolo
Fortran preserves () in expressions - in many cases, it shouldn't need to do so
if
-fno-protect-parens is specified. The option currently affects only the middle
end, but there might be some cases where it is preserved without needing to be.
(Though, I might be wrong and everything is already
--- Comment #7 from jobnoorman at gmail dot com 2010-08-18 14:03 ---
(In reply to comment #3)
Looking at the diagnostics issued when -pedantic is added, I think the right
conversion is
(void*)(plain_foobar_t)Foo::foobar
That still uses the G++ extension, and doesn't give the asm
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90
-B/mnt/gnu/gcc/objdir/hp
pa2.0w-hp-hpux11.11/./libgomp/
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./lib
gomp/.libs
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 14:23 ---
(In reply to comment #0)
In some cases, one might need to check for the unsave_math_optimization flag
before changing, e.g., 2+(a-2) to a - or rather (a).
The whole point of PAREN_EXPR in the middle-end is to
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-18 14:32 ---
Similar fails:
FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for warnings, line 11)
FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for excess errors)
Excess errors:
--- Comment #24 from bernds at gcc dot gnu dot org 2010-08-18 14:36 ---
It should be possible to do better in cselib_subst_to_values - for POST_* we
could look up the value of the inner expression, and for PRE_* we could
probably construct a PLUS of some kind. That would be an
--- Comment #28 from mikael at gcc dot gnu dot org 2010-08-18 14:40 ---
(In reply to comment #27)
This is a very good suggestion. I will have a think about how to implement it
and will come back to you. It is consistent with what I had in mind to
improve
the efficiency of module
The following code fails to detect breaking of strict-aliasing rules correctly:
#include stdio.h
int main()
{
int i;
float A[20];
for (i = 0; i 20; i++)
{
A[i] = i;
--- Comment #2 from paolo at gcc dot gnu dot org 2010-08-18 15:22 ---
Subject: Bug 45276
Author: paolo
Date: Wed Aug 18 15:21:56 2010
New Revision: 163342
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163342
Log:
2010-08-18 Kostya Serebryany k...@google.com
Paolo
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 15:24
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-18 15:28
---
In general terms, ins't true that the warnings produced at -O0 are often much
weaker than when optimizing? I don't see anything aliasing-specific here...
--
Attempting to bootstrap gcc-4.6-20100814 (r163252) on arm-linux-gnueabi fails
due to a warning in stage2 and the default use of -Werror there:
/home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c: In function
'arm_get_pcs_model':
/home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c:3720:7: error:
--- Comment #1 from mikpe at it dot uu dot se 2010-08-18 15:43 ---
Created an attachment (id=21511)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21511action=view)
proposed fix
The issue is that stdarg_p has a non-const parameter but the call site in the
ARM backend has a const
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-08-18 16:06 ---
Subject: Bug 45049
Author: froydnj
Date: Wed Aug 18 16:05:40 2010
New Revision: 163344
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163344
Log:
gcc/cp/
PR c++/45049
* name-lookup.c
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-08-18 16:07 ---
Fixed.
--
froydnj at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-18 16:10 ---
At -O2 -Wstrict-aliasing=1 warns for me. I can't reproduce warnings
with -O0 or with -O1 because at those levels strict-aliasing isn't enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320
--- Comment #6 from fang at csl dot cornell dot edu 2010-08-18 16:30
---
Created an attachment (id=21512)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21512action=view)
test case, semi-reduced, day 3
day 3 of reducing, 4.5k lines
--
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-18 17:44 ---
(In reply to comment #1)
(In reply to comment #0)
In some cases, one might need to check for the unsave_math_optimization flag
before changing, e.g., 2+(a-2) to a - or rather (a).
The whole point of
--- Comment #8 from ian at airs dot com 2010-08-18 17:44 ---
Just for the record, I'm with Jakub: the general rule should be that r always
works for a value that fits in a register, and anything else requires enabling
optimization to work reliably.
I don't see why we should sign up to
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-18 18:06 ---
Subject: Bug 45295
Author: burnus
Date: Wed Aug 18 18:05:58 2010
New Revision: 163347
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163347
Log:
2010-08-18 Tobias Burnus bur...@net-b.de
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-18 18:07 ---
FIXED
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pault at gcc dot gnu dot org 2010-08-18 18:55 ---
Created an attachment (id=21513)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21513action=view)
The beginings of a fix
This PR is going to drive me mad!
The immediate cause is a failure to get the
--- Comment #25 from jakub at gcc dot gnu dot org 2010-08-18 19:00 ---
Alex Oliva posted some patches to make cselib handle autoinc stuff.
No idea whether http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01038.html
is the latest version or if he has a newer one.
--
jakub at gcc dot gnu
libtool: compile: libobj name `ltdl.lo' may not contain shell special
characters.
make[4]: *** [ltdl.lo] Error 1
make[4]: Leaving directory
`/home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libjava/libltdl'
make[3]: *** [all] Error 2
make[3]: Leaving directory
Just warnings, not errors.
/home/jayk/src/gcc-4.5.1/libgfortran/io/write.c: In function 'nml_write_obj':
/home/jayk/src/gcc-4.5.1/libgfortran/io/write.c:1504:8: warning: array
subscript has type 'char'
/home/jayk/src/gcc-4.5.1/libgfortran/io/write.c:1511:4: warning: array
subscript has type
--- Comment #9 from domob at gcc dot gnu dot org 2010-08-18 19:34 ---
Created an attachment (id=21514)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21514action=view)
Partial patch.
This implements rank remapping and also bounds remapping as for PR 45016.
Tests seem to be
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-18 19:40 ---
That's the lines:
1472char cup;
1467size_t dim_i;
1504cup = toupper (base_name[dim_i]);
1511cup = toupper (obj-var_name[dim_i]);
and
1743char c;
1741index_type
--- Comment #3 from changpeng dot fang at amd dot com 2010-08-18 19:43
---
*** Bug 45269 has been marked as a duplicate of this bug. ***
--
changpeng dot fang at amd dot com changed:
What|Removed |Added
--- Comment #2 from changpeng dot fang at amd dot com 2010-08-18 19:43
---
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html
Verified. If I back out the above change, the bug goes away.
So it is a duplicate of bug 44206
*** This bug has been marked as a duplicate of 44206 ***
--
--- Comment #7 from t dot artem at mailcity dot com 2010-08-18 20:00
---
I bet this bug can be triggered in a VM (e.g. in VirtualBox) too, so I'll try
to debug it later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
--- Comment #26 from ubizjak at gmail dot com 2010-08-18 20:13 ---
Splitting to LEA was fixed in r163351 [1] with patch at [2].
[1] http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00562.html
[2] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01394.html
--
ubizjak at gmail dot com changed:
--- Comment #7 from fang at csl dot cornell dot edu 2010-08-18 20:13
---
Created an attachment (id=21515)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21515action=view)
test case, day 3b
yet smaller
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
When gcc is configured with i586-linux, I got
FAIL: gcc.target/i386/volatile-bitfields-1.c scan-assembler movzbl.*bits
I don't see anything wrong with
.cfi_startproc
movbbits, %al
sarb%al
movsbl %al, %eax
ret
.cfi_endproc
I think we
[...@gnu-36 gcc]$ cat
../../../../src-trunk/gcc/testsuite/gcc.target/i386/pr38240.c
/* { dg-do compile } */
typedef float V
__attribute__ ((__vector_size__ (16), __may_alias__));
V __attribute__((target(sse))) f(const V *ptr) { return *ptr; }
V g(const V *ptr) { return *ptr; }
[...@gnu-36
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 20:31 ---
Well - obviously global typedefs keep their BLKmode. The target attribute
can't work this way - it's broken by design.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-18 20:58 ---
WONTFIX for an ICE seems a bit odd to me.
Just needs a diagnostic to reject nonsense target attributes, or a sorry. But
not an ICE.
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #12 from hjl at gcc dot gnu dot org 2010-08-18 21:08 ---
Subject: Bug 45292
Author: hjl
Date: Wed Aug 18 21:08:24 2010
New Revision: 163353
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163353
Log:
Expand pending pops before trying the optab.
2010-08-18 H.J. Lu
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-18 21:18 ---
Well, I think we should back out support for that option. The set of
nonsensical options doesn't include sse - but all options are included
in the set of broken options. At least I expect that you can create a
I seem to keep running into inttypes.h/stdint.h that aren't quite adequate,
esp. for gmp. For example, in mpfr:
https://gforge.inria.fr/scm/viewvc.php/trunk/get_uj.c?view=logroot=mpfrpathrev=7083#rev7082
Anyway, I suggest this to reduce the problem:
bash-4.1$ diff -u Makefile.in.orig
--- Comment #1 from jay dot krell at cornell dot edu 2010-08-18 21:27
---
example error:
file included from /home/jayk/src/gcc-4.5.1/gmp/assert.c:27:0:
/home/jayk/src/gcc-4.5.1/gmp/gmp-impl.h:188:29: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'gmp_uint_least32_t'
Command line:
$ gcc -O1 -funroll-loops -fnon-call-exceptions testcase.c
Valgrind output:
==17265== Invalid read of size 2
==17265==at 0x82C2FB: rtx_equal_p (rtl.c:495)
==17265==by 0xA6781A: ix86_swap_binary_operands_p (i386.c:14395)
==17265==by 0xA8F448: ix86_binary_operator_ok
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 21:49 ---
Hm, Bernd - you recently touched that code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fang at csl dot cornell dot edu 2010-08-18 22:05
---
reduced test case (manually reduced after delta):
===
typedef long unsigned int size_t;
template class T struct never_ptr {
T* ptr;
T* operator - () const
--- Comment #2 from ubizjak at gmail dot com 2010-08-18 22:13 ---
Patch that fixes the failure:
Index: i386.md
===
--- i386.md (revision 163353)
+++ i386.md (working copy)
@@ -8456,7 +8452,7 @@
--- Comment #3 from ubizjak at gmail dot com 2010-08-18 22:24 ---
(In reply to comment #2)
Patch that fixes the failure:
This is actually {i,x}or_{qi,hi,si,di}_3 pattern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-18 22:32 ---
Subject: Bug 45290
Author: janus
Date: Wed Aug 18 22:32:22 2010
New Revision: 163356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163356
Log:
2010-08-19 Janus Weil ja...@gcc.gnu.org
PR
Given this code,
#include initializer_list
typedef std::initializer_listint init_list;
struct A {
A (init_list list) { }
};
struct B {
B (std::initializer_listint list) { }
};
int main (void) {
A a { 0, 1, 1, 2}; // compiler error
B b { 0, 1, 1, 2};
}
I get a compiler error when
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-18 22:37 ---
r163356 implements pointer initialization.
Leftover To-Do items:
(1) ICE on
module m
implicit none
integer, target, save :: t1
integer, pointer :: p1 = t
integer, pointer :: p2 = p1! ICE
end module m
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-18 22:42 ---
*** This bug has been marked as a duplicate of 23200 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #44 from pinskia at gcc dot gnu dot org 2010-08-18 22:42
---
*** Bug 45303 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uros at gcc dot gnu dot org 2010-08-18 22:37 ---
Subject: Bug 45327
Author: uros
Date: Wed Aug 18 22:37:03 2010
New Revision: 163357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163357
Log:
PR target/45327
* config/i386/i386.md
--- Comment #6 from ubizjak at gmail dot com 2010-08-18 22:47 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-18 22:54 ---
possibly related to Bug 44703, although that's fixed in 4.5.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-18 23:08
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-18 23:11
---
Let's CC Jason.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 23:19
---
Actually, both mainline and the released 4.5.1 work, most likely a duplicate of
PR 44703 indeed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-08-19 02:36
---
Subject: Bug 41859
Author: jvdelisle
Date: Thu Aug 19 02:35:45 2010
New Revision: 163363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163363
Log:
2010-08-19 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-08-19 03:52
---
Created an attachment (id=21516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21516action=view)
Proposed patch
This patch will generate an error. If IOSTAT or IOMSG is used, the read will
continue in the
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-08-19 04:01
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Consider the following sample program:
struct S
{
int x;
int y;
};
int foo(int x, int y)
{
return x+y;
}
int foo(const S s)
{
return s.x + s.y;
}
int foo2(int x)
{
foo(x);
}
When compiling this, clang prints:
# clang ./tst.cc
./tst.cc:19:3: error: no matching function for call to
Consider this code sample:
namespace N
{
int foo;
}
int bar()
{
return foo;
}
GCC, generates the following error:
tst.cc: In function int bar():
tst.cc:8:10: error: foo was not declared in this scope
It would be nice if it suggested that the user might mean N::foo.
--
Consider this sample code:
# cat tst.cc
class X
{
public:
int a;
}
int foo(const X x)
{
return x.a;
}
The clang front end generates a very nice warning (which is actually color
coded for ease of readability):
# clang ./tst.cc
./tst.cc:5:2: error: expected ';' after class
}
^
;
1
Consider the following sample code:
# cat tst.cc
class C
{
int x
const int foo() { return x; }
};
Clang generates the following diagnostics:
# clang tst.cc
tst.cc:3:8: error: expected ';' at end of declaration list
int x
^
;
1 diagnostic generated.
By comparison, gcc
Consider the following code sample:
#define ZERO(c) c.set(0)
struct S
{
int a;
int b;
};
template class T
class C
{
T t;
public:
void set(int x) { t = x; }
};
void foo(CS c)
{
ZERO(c);
}
When compiled with clang, the instantiation backtrace shows the point of
instantiation within the
80 matches
Mail list logo
