---BeginMessage---
Hi,
if I define this type:
typedef unsigned char UCHAR __attribute__((aligned(32)));
void func(void) {
char example;
UCHAR vector[40];
...
}
The vector array is 4 byte alignment in any case?
Regards Michael
---End Message---
On 11/19/06, Eric Weddington [EMAIL PROTECTED] wrote:
Use gcc head, __builtin_bswap and make sure the AVR backend
implements the
bswap rtl patterns.
There's the problem. You can't just glibly say make sure the AVR backend
implements the bswap rtl patterns. There are precious few volunteers
On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
while speaking about uninitialized variables gcc developers probably
want
to look at their own sources first:
gcc/testsuite/gcc.dg/vect/vect-27.c
If any code in the testsuite is broken, it should be changed.
should be fixed now
Bruce,
On Thu, 19 Oct 2006, Bruce Korb wrote:
I was going to re-subscribe my dropped subscription to gcc-patches,
but the only links (that I can find) on gcc.gnu.org lead to the archives,
not to the subscription page. Thanks - Bruce
I understand your immediate issue has been addressed
On Wed, 4 Oct 2006, Daniel Jacobowitz wrote:
This file can be found in the same directory that
contains cc1 (run gcc -print-prog-name=cc1 to find it).
I think that indicates someone trying to be overly clever when they
configured your gcc package. Normally libdir and libexecdir
On 11/15/06, Richard Guenther [EMAIL PROTECTED] wrote:
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Andrew Haley [EMAIL PROTECTED] writes:
2006-11-07 Paolo Bonzini [EMAIL PROTECTED]
* gimplify.c (fold_indirect_ref_rhs): Use
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 19, 2006 3:55 AM
To: Eric Weddington
Cc: Paul Brook; gcc@gcc.gnu.org; Shaun Jackman;
avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Re: AVR byte swap optimization
On 11/19/06, Eric
On 19 November 2006 16:07, Gerald Pfeifer wrote:
On Wed, 4 Oct 2006, Daniel Jacobowitz wrote:
This file can be found in the same directory that
contains cc1 (run gcc -print-prog-name=cc1 to find it).
I think that indicates someone trying to be overly clever when they
configured
On Sun, Nov 19, 2006 at 08:31:22AM -0700, Eric Weddington wrote:
Rask, do you have FSF paperwork in place?
Yes, it was completed recently.
--
Rask Ingemann Lambertsen
Hello,
I'm running into some troubles with an if-conversion pass that runs
after reload, where we have to avoid lifting insns across a loop
exit edge into a loop. ifcvt.c uses flow_loops_find to find loops
and mark all loop exit edges:
if ((! targetm.cannot_modify_jumps_p ())
On Fri, Nov 17, 2006 at 04:30:53PM -0700, Shaun Jackman wrote:
Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
with -O2.
I won't bother to show bswap_32 here, which produces a real disaster!
Think 47 instructions, for what should be 6.
You may get better code if
Let me know if that works for you.
After applying the Andrew Pinski's patch for pr29879, the build of snapshot
20061118 went without problem on OSX 10.3.9. So your patch fixes the
problem I have reported. Thanks a lot.
If I may abuse of the situation, I am using the following patches:
Index:
Can any one get me the information/implementation of below mentioned
functions?
1. operands[0] = gen_rtx_REG (SImode,REGNO (set_dest));
2. operands[0] = gen_highpart (SImode, set_dest);
Sure, emit-rtl.c, lines 488 and 1165.
Ben
It isn't only on the AVR that bswap_32() is nontrivial to get
right.
These two versions would rule on the i386 if GCC would be just a
little bit
smarter:
I prefer the single instruction bswap that we now generate for
__builtin_bswap[32,64] myself...
-eric
On a somewhat related note, I'd be interested to hear if ccache
could be snuck into bootstrapping to speed up recompiles in the
intermediate stages, especially with incremental changes. (Anyone
tried this?) I've noted that ccache-ing only speeds up the first
stage, as one would expect.
There might be a subtle issue with ccache assuming that the compiler
that created a cache-hit object did not change. I'm only aware of
ccache verifying compiler versions (string compare) in the
hit-check, which alone doesn't suffice to guarantee that the cache
is (or should be) hit.
[EMAIL PROTECTED] wrote:
So, are we using P1 instead to mark release-blocking bugs? Should
we fix the severities of existing bugs?
I am using priorities to indicate how important it is to fix a bug
before the next release. This is consistent with the meanings of the
terms priority and
In the meantime, is there a simple way to disable this more correct
mechanism so I can get my timings?
You'll get testsuite failures if you disable it because it fixes a
bunch of bugs.
You can always disable all of PTA, but i would not recommend it.
With the attached patch, it should take
--- Comment #2 from Jean-pierre dot vial at wanadoo dot fr 2006-11-19
08:55 ---
(In reply to comment #1)
This is a bug in your instation of GMP/MPFR. It is causing gfortran to crash.
No, I found the explanation, it has nothing to do with gmp:
it is a parallelism problem in the
--- Comment #18 from kreckel at ginac dot de 2006-11-19 11:22 ---
An idea: Would it help if feholdexcept, fetestexcept and all those standard
functions accessing the status and control flags were implemented as builtins,
not as extern libcalls?
This probably wouldn't help against
see also: http://gcc.gnu.org/ml/fortran/2006-11/msg00511.html
With -fbounds-check, an error message is shown if the character substrings
exceed the size of the variable. This error message contains also the name of
the variable, but this piece of information is not always passed to
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-11-19 12:14
---
The problem is that the division is in no ways special to optimizers. One
possibility I see would be to introduce either a builtin function or a new
tree-code to access the exception flags. Of course the fact
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-19 12:51
---
I need to do the same for array bounds checking, to identify the cases where no
name is provided and see what we can do about it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at
I just tried to compile Linux kernel version 2.6.18.2
with gcc-4.3-20061118 snapshot on a x86_64 box.
The compiler said
/home/dcb/gnu/43-20061118/results/bin/gcc -g -O3 -Wall -march=opteron
-Wp,-MD,arch/x86_64/lib/.csum-partial.o.d -nostdinc -isystem
--- Comment #1 from dcb314 at hotmail dot com 2006-11-19 13:37 ---
Created an attachment (id=12644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12644action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29895
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2006-11-19
13:41 ---
*** This bug has been marked as a duplicate of 29879 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2006-11-19
13:41 ---
*** Bug 29895 has been marked as a duplicate of this bug. ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 13:54
---
since source is too large (~1.7MB) to attach i uploaded it for your
convenience, please download it from here:
http://oscc.sourceforge.net/compiler.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** This bug has been marked as a duplicate of 29896 ***
--
baraclese at googlemail dot com changed:
What|Removed |Added
--- Comment #2 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** Bug 29893 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** This bug has been marked as a duplicate of 29896 ***
--
baraclese at googlemail dot com changed:
What|Removed |Added
--- Comment #3 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** Bug 29894 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
In gcc/config/sh/symbian.c there is this code:
warning (0, %s %q+D %s after being referenced with dllimport linkage,
TREE_CODE (decl) == VAR_DECL ? variable : function,
decl, (DECL_INITIAL (decl) || !DECL_EXTERNAL (decl))
? defined locally :
The following program fails to compile with every version of GCC 4.x I
tested (including current mainline) with
error: no match for call to '(const __gnu_cxx::hashlong long int) (const
long
long int)'
snip
#include ext/hash_set
using namespace __gnu_cxx;
typedef long
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-11-19 14:58
---
Working on this
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-19 14:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-11-19 15:06 ---
Hi Gerald. The libstdc++ project already decided to not work anymore on the
legacy ext/ containers (beyond serious bugs affecting existing facilities,
maybe), because these days there is no reason to not move to the
--- Comment #2 from pcarlini at suse dot de 2006-11-19 15:12 ---
PS: per the letter of TR1, the new hashing facilities in TR1 also miss
specializations of struct hash for long long and unsigned long long, I'm going
to add those, as a reasonable extension (anyway, long long is already
--- Comment #11 from bonzini at gnu dot org 2006-11-19 15:52 ---
thanks, this patch seems ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:09 ---
Subject: Bug 2
Author: rguenth
Date: Sun Nov 19 16:09:19 2006
New Revision: 118988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118988
Log:
2006-11-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #4 from steven at gcc dot gnu dot org 2006-11-19 16:10 ---
The best way to reduce this test case is to use
--param ggc-min-expand=0 -- param gcc-min-heapsize=0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:15 ---
Subject: Bug 29753
Author: rguenth
Date: Sun Nov 19 16:14:49 2006
New Revision: 118989
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118989
Log:
2006-11-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 ---
Subject: Bug 29753
Author: rguenth
Date: Sun Nov 19 16:15:47 2006
New Revision: 118990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118990
Log:
2006-11-19 Richard Guenther [EMAIL PROTECTED]
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 ---
Fixed on 4.1 and 4.2 branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:18 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
I work for a long time on a programming language and it is written in C, F77
and F90. I can build this code with all release of gcc/gfortran before the
4.1.x.
I have tried to found a bug in my code without any success, thus, I write this
bug report.
Test program:
schroedinger:[~/test]
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 18:01 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-19 18:19 ---
I though I had replyed to my last comment, but seemingly I forget to Commit
the comment.
I tested with de and zh_TW (Zhonghua/Taiwan alias Guoyu) locale and the result
is ok. [Well, in Chinese it least it looks as if
--- Comment #9 from danglin at gcc dot gnu dot org 2006-11-19 18:24 ---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 18:24:21 2006
New Revision: 118993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118993
Log:
PR target/29114
* pa.c (emit_move_sequence):
--- Comment #10 from danglin at gcc dot gnu dot org 2006-11-19 18:27
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 18:27:03 2006
New Revision: 118994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118994
Log:
PR target/29114
* pa.c (emit_move_sequence):
--- Comment #11 from danglin at gcc dot gnu dot org 2006-11-19 19:06
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 19:06:09 2006
New Revision: 118995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118995
Log:
PR target/29114
* pa.c (emit_move_sequence):
--- Comment #12 from danglin at gcc dot gnu dot org 2006-11-19 19:09
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 19:09:04 2006
New Revision: 118996
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118996
Log:
PR target/29114
* pa.c (emit_move_sequence):
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00141.html
triggers uninitialized read of stack register on x86. The testcase is
# cat foo.f90
MODULE foo
CONTAINS
SUBROUTINE SWPARA(IU, JU, IIL, JJL, XI, YJ, XALB, kts,kte)
INTEGER, INTENT(IN ) :: kts,kte
INTEGER,
--- Comment #13 from danglin at gcc dot gnu dot org 2006-11-19 20:11
---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:21 ---
I think this was already fixed via:
2006-11-14 Paolo Bonzini [EMAIL PROTECTED]
PR rtl-optimization/29798
* fwprop.c (use_killed_between): Check that DEF_INSN dominates
TARGET_INSN before
--- Comment #2 from hjl at lucon dot org 2006-11-19 20:35 ---
Created an attachment (id=12645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12645action=view)
RTL stack dump
I am using:
gcc version 4.3.0 20061115 (experimental) [trunk revision 118860]
RTL stack dump still shows
$ gcc -Wstrict-aliasing -fstrict-aliasing -c test.c
test.c: In function f1:
test.c:2: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ cat test.c
void f2(char **p);
void f1(unsigned char *bits) { f2((char **)bits); };
$
but:
the same address as an object of
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-19 20:42 ---
Created an attachment (id=12646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12646action=view)
Latest update
Here's the latest update of the patch, for reading, writing and
backspace.
In order to be able to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:46 ---
(In reply to comment #0)
but:
the same address as an object of a different type, unless the
types are almost the same. For example, an `unsigned int' can
alias an `int', but not a `void*' or a
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-19 20:47 ---
This looks like a latent bug in regstack really, the dumps before regstack are
ok in that reg 11 is initialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-19 20:50 ---
the only thing fwprop does in this case is props the address.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 21:01 ---
regstack is broken.
Before:
(insn:TI 70 69 71 3 (set (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(plus:SF (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(reg:SF 12 st(4) [orig:70 pretmp.92 ] [70])))
--- Comment #10 from tbm at cyrius dot com 2006-11-19 21:09 ---
(In reply to comment #9)
That would fix it perfectly fine, i'll bootstrap and test it.
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-11-19 21:10
---
(In reply to comment #9)
Created an attachment (id=12643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12643action=view) [edit]
New patch, the old one could cause a seg fault also during bootstrap
I
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-11-19 21:30
---
Commited to mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-19
21:55 ---
Subject: Re: Shared libstdc++ fails to link
On Mon, Nov 13, 2006 at 02:37:02AM -, pinskia at gcc dot gnu dot org wrote:
This problem was introduced by this change:
That makes less sense really,
--- Comment #13 from dominiq at lps dot ens dot fr 2006-11-19 22:11 ---
Applied to snapshot 4.3-20061118 on OSX 10.3, seems ok for me too, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
--- Comment #1 from andreast at gcc dot gnu dot org 2006-11-19 22:13
---
Last working rev is 118744, the failure appears in 118746. But not clear why.
Andreas
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 22:26 ---
I want to say the gen_insn part which exposed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
I get the following ICE with 4.2.0 20061116 with -fprefetch-loop-arrays:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O3
libjingle0.3-xmppclient.cpp [EMAIL PROTECTED]:~$
/usr/lib/gcc-snapshot/bin/g++ -c -O -fprefetch-loop-arrays
libjingle0.3-xmppclient.cpp
--- Comment #1 from tbm at cyrius dot com 2006-11-19 22:31 ---
Created an attachment (id=12648)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12648action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:14 ---
Reduced testcase:
struct filename_pool
{
struct holder
{
friend void intrusive_ptr_release(holder* p){}
};
friend void intrusive_ptr_release(holder*);
};
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-19 23:16 ---
This is a dup of bug 27100.
*** This bug has been marked as a duplicate of 27100 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 23:16 ---
*** Bug 29896 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:23 ---
Adding Roger as CC because this is a bug in regstack as far as I can tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-20
00:22 ---
Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE:
Segmentation fault
I want to say the gen_insn part which exposed the problem.
I still have the ICE after reverting this part.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-20 00:23 ---
Reduced testcase:
int length1();
int g(int);
void f(int capacity_, char *old_storage)
{
try {
length1();
int old_capacity = capacity_;
capacity_ *= 2;
g(capacity_);
for (int i = 1; i
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-20 00:27 ---
I think after remove empty loops, we should add a DCE pass which should fix the
above reduced testcase but will not fix this reduced testcase:
int length1();
int g(int);
void f(int capacity_, char*old_storage)
{
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29899
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c
-w -O3 -g -fno-show-column -lm -o
/home/dave/gcc-4.3/objdir/gcc/testsuite/g
cc/mayalias-3.x4(timeout = 300)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-20 00:49 ---
It is the same failure as mayalias-2.c as I added both, the code is only
slightly different between those two.
*** This bug has been marked as a duplicate of 28834 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-20 00:49
---
*** Bug 29903 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from gdr at gcc dot gnu dot org 2006-11-20 01:04 ---
Subject: Bug 8586
Author: gdr
Date: Mon Nov 20 01:03:49 2006
New Revision: 119009
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119009
Log:
2006-11-19 Gabriel Dos Reis [EMAIL PROTECTED]
PR c++/8586
90 matches
Mail list logo
