According to http://gcc.gnu.org/bugs.html here is what is requested for
a bug report.
Regards,
Miguel Luis.
## the exact version of GCC;
$ gcc --version
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying
--- Comment #7 from cgf at gcc dot gnu dot org 2007-05-08 13:04 ---
reverting spamassassin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31858
--- Comment #8 from cgf at gcc dot gnu dot org 2007-05-08 13:06 ---
I reverted spamassassin to v3.1.8.
Comments on the net seemed to indicate that 3.2.0 was slower anyway and it
certainly doesn't seem ready for prime time yet.
--
cgf at gcc dot gnu dot org changed:
What
With -O1, the following testcase
int
foo (void)
{
return ({
unsigned int resultvar = ({
long int arg = (long int) 0;
register long int reg asm (eax) = arg;
asm volatile (nop
: =a (resultvar)
: 0 (reg)
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-08 13:45 ---
Subject: Bug 31692
Author: pault
Date: Tue May 8 12:45:31 2007
New Revision: 124546
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124546
Log:
2007-05-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 13:49 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-08 13:51 ---
I'll submit a fix tonight.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-08 13:51 ---
I'll submit a fix tonight.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-08 13:52 ---
Oops!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #1 from dnovillo at acm dot org 2007-05-08 14:10 ---
Subject: Re: New: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 07:59:03 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
See http://openmp.org/pipermail/omp/2007/000840.html
and the
--- Comment #12 from angray at beeb dot net 2007-05-08 15:07 ---
(In reply to comment #11)
MSC includes the calling convention as part of its C++ name mangling. Would
this bug be easier to solve if the calling convention was also included as
part
of the C++ name mangling in GCC,
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 ---
WTF, this is just sad we have to disable optimizations because openmp folks
don't know how to program threaded code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #13 from bangerth at dealii dot org 2007-05-08 15:34 ---
(In reply to comment #12)
The summary says g++ misses warning for on temporary. But something that
is
always an error can be called a warning?
The point is that the standard doesn't call it an error, but
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:35 ---
EDG accepts this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 ---
*** This bug has been marked as a duplicate of 31793 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 ---
*** Bug 31865 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:37 ---
OMP is not a good generic programming model for threaded code. Exactly because
of this issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--- Comment #4 from dnovillo at acm dot org 2007-05-08 15:39 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:30:45 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 15:41 ---
Subject: Bug 31630
Author: pault
Date: Tue May 8 14:40:58 2007
New Revision: 124550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124550
Log:
2007-05-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from dnovillo at acm dot org 2007-05-08 15:44 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:37:05 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
OMP is not a good generic programming model for threaded code.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:45 ---
Created an attachment (id=13530)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13530action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-08 15:47 ---
This is related to PR29433, but still unresolved.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:52 ---
Until I killed cc1plus we have (mainline):
samples %symbol name
5011528.3000 push_fields_onto_fieldstack
12370 6.9853 bitpos_of_field
10174 5.7453 tree_low_cst
8825 4.9835
On 8 May 2007 14:44:16 -, dnovillo at acm dot org
[EMAIL PROTECTED] wrote:
The original code did not have a race condition. The compiler
transformations introduced a race-condition. This *is* a compiler
bug.
Actually the original code has a race condition, if another thread is
reading
--- Comment #6 from pinskia at gmail dot com 2007-05-08 15:59 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:44:16 -, dnovillo at acm dot org
[EMAIL PROTECTED] wrote:
The original code did not have a race condition. The compiler
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-08 16:01 ---
cc1plus: out of memory allocating 1764584 bytes after a total of 16482304
bytes
so this actually killed even the 16GB box.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-08 16:03 ---
Danny, push_fields_onto_fieldstack is going crazy on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from james dot kanze at gmail dot com 2007-05-08 16:11
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 7 May 2007 21:08:05 -, gianni at mariani dot ws
[EMAIL PROTECTED] wrote:
--- Comment #35 from gianni at mariani dot ws
--- Comment #38 from james dot kanze at gmail dot com 2007-05-08 16:21
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 8 May 2007 05:24:35 -, gianni at mariani dot ws
[EMAIL PROTECTED] wrote:
--- Comment #36 from gianni at mariani dot ws
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-08 16:21 ---
Note the interesting debuggable testcase is if you remove from getInstance()
all
template params from ClassSpecKey, A020, 21 on. Around that one you'll
clearly
see exponential behavior in memory use ;)
--
The program
module util_mod
implicit none
contains
function join(words,sep) result(str)
! trim and concatenate a vector of character variables,
! inserting sep between them
character (len=*), intent(in):: words(:),sep
character (len=(size(words)-1)*len(sep) + sum(len_trim(words))) :: str
--- Comment #3 from simartin at gcc dot gnu dot org 2007-05-08 16:34
---
Subject: Bug 31847
Author: simartin
Date: Tue May 8 15:33:56 2007
New Revision: 124551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124551
Log:
2007-05-08 Simon Martin [EMAIL PROTECTED]
PR
--- Comment #4 from simartin at gcc dot gnu dot org 2007-05-08 16:47
---
This should be fixed (see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00527.html for an explanation of
the patch).
--
simartin at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from raf2 at msux dot cjb dot net 2007-05-08 17:18 ---
I first was hit by an error using MinGW... when I compiled and executed the
first attached file, it wrote:
John drives a: bus
Otto drives a: bus
Which was wrong, I reported the bug and a guy from
--- Comment #15 from raf2 at msux dot cjb dot net 2007-05-08 17:22 ---
Created an attachment (id=13531)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13531action=view)
File with wrong code that leads to an unexpected result
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #16 from bangerth at dealii dot org 2007-05-08 17:25 ---
(In reply to comment #14)
Which was wrong, I reported the bug and a guy from MinGW kindly explained that
if it worked then that would be purely by accident and added:
When you declare the argument without '' then
X86-64 crtend.o with DWARF EH is broken when compiled with
-fasynchronous-unwind-tables, which is the default:
http://gcc.gnu.org/ml/gcc/2002-11/msg00799.html
It was fixed for Linux only:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01671.html
That leaves all non-Linux x86-64 with DWARF EH
--- Comment #1 from hjl at lucon dot org 2007-05-08 18:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00557.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
--- Comment #5 from ismail at pardus dot org dot tr 2007-05-08 18:48
---
I had to apply http://gcc.gnu.org/viewcvs?view=revrevision=122255 to the 4.2.0
branch to be able to bootstrap, else I get :
from gcc-4.2.0-20070430/libstdc++-v3/include/precompiled/stdc++.h:71:
--- Comment #2 from hjl at lucon dot org 2007-05-08 18:55 ---
Patches against 4.1, 4.2 and 4.3 are at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00563.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
--- Comment #6 from ismail at pardus dot org dot tr 2007-05-08 19:02
---
Never mind my last comment, it was a local patch causing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 ---
This really is not specific to OpenMP, I believe the following is valid
threaded program:
#define _XOPEN_SOURCE 600
#include pthread.h
#include stdlib.h
int v;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
--- Comment #8 from pinskia at gmail dot com 2007-05-08 19:45 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 18:08:26 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #39 from pcarlini at suse dot de 2007-05-08 19:50 ---
The proper status of this PR is SUSPENDED. Today, mid of 2007, we all more or
less concur that string is better implemented without reference-counting,
optimized for short strings, and, of course, exploiting rvalue
--- Comment #13 from mark at codesourcery dot com 2007-05-08 20:11 ---
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote:
--- Comment #11 from rridge at csclub dot
#include stdio.h
#define MKSTR(x) STR(x)
#define STR(x) #x
#define EMPTY /* nothing */
int main(void) {
puts(MKSTR(.EMPTY.));
puts(MKSTR(.EMPTY .));
}
Using gcc 4.1.2, configured with
../gcc-4.1.2/configure --prefix=$HOME/gcc --enable-languages=c,c++
--disable-multilib, on
--- Comment #7 from fang at csl dot cornell dot edu 2007-05-08 20:44
---
Still accepts-invalid as of 4.2-20070430 (RC2).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #9 from fang at csl dot cornell dot edu 2007-05-08 20:48
---
Still accepts-invalid with 4.2-20070430 (RC2).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #2 from dorit at il dot ibm dot com 2007-05-08 21:00 ---
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
This is the loop we analyze:
# prephitmp.192_37 = PHI storetmp.191_30(3), D.1443_42(5)
# i_1 = PHI 1(3), i_44(5)
--- Comment #2 from sje at cup dot hp dot com 2007-05-08 21:18 ---
I am seeing this slow compile too. It compiles OK on HPPA in 32 bit mode (1.5
minutes) but takes over 30 minutes in 64 bit mode. It also takes 6+ minutes on
IA64 HP-UX. On an X86 box it took less than 1 minute.
Using
--- Comment #7 from spop at gcc dot gnu dot org 2007-05-08 21:19 ---
Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
On 5/8/07, Sjodin, Jan [EMAIL PROTECTED] wrote:
Okay, I looked at the code, and the problem is that we have to pass to
--- Comment #8 from Jan dot Sjodin at amd dot com 2007-05-08 21:30 ---
Subject: RE: -ftree-vectorize results in
internal compiler error on AMD64
I would prefer to make it work instead of disabling the vectorizer for
these cases.
- Jan
-Original Message-
From: [EMAIL
--- Comment #3 from sje at cup dot hp dot com 2007-05-08 21:55 ---
I now think the loc_mentioned_in_p calls are coming from the checking code at
the top of subst_reload. I commented out this checking code and my compile
speed up by more than 10X.
--
sje at cup dot hp dot com
--- Comment #14 from angray at beeb dot net 2007-05-08 22:02 ---
(In reply to comment #13)
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote:
--- Comment #11 from
--- Comment #35 from mmitchel at gcc dot gnu dot org 2007-05-08 22:05
---
Ian Taylor suggests:
The way to fix this is to add a HOST_HOOKS_GT_PCH_GET_ADDRESS to
host-solaris.c. That hook should try to allocate the space in some
address area that is normally free on Solaris. See the
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-08 23:08
---
Created an attachment (id=13532)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13532action=view)
New patch
Here's a new patch from a completely different perspective, using C99 lround
and llround functions
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-05-08 23:11 ---
It turned out that this is a generic reload issue rather than
a target problem. See
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00476.html
--
kkojima at gcc dot gnu dot org changed:
What
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-08 23:15 ---
This patch would fix it, but it's brute-force and it causes a ~1.5% slowdown.
Some form of DCE a little more delicate than this will be necessary to fix this
bug, though.
Index: cfgcleanup.c
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-08 23:23 ---
Subject: Bug 28011
Author: kkojima
Date: Tue May 8 22:22:49 2007
New Revision: 124557
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124557
Log:
PR rtl-optimization/28011
* reload.c
int d (void) { register int a[2]; return a, 1; }
--
Summary: Failure to diagnose taking address of register variable
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Casts to void * are not permitted in integer constant expressions.
Therefore this code violates constraint 6.7.5.2p2 of C99 (C90 is u.b.) and so
must be diagnosed.
extern int c[1 + ((int) (void *) 0)];
--
Summary: C99 failure to diagnose non-integer cast
Product: gcc
Compiling 27_io/basic_istream/extractors_arithmetic/char/12.cc with
-g3 -O0, I get the error:
/var/tmp//ccLYgR4g.s: Assembler messages:
/var/tmp//ccLYgR4g.s:424: Error: file number 1 already allocated
This is the full compilation command:
/test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-09 00:52 ---
Oops, this is against 4.3.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-09 01:10
---
I will look this over tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-09 01:33
---
I get:
words = 'two three'
On x86-64-gnu/linux with latest 4.3
I wonder if this is one that we recently fixed. Can you try with a more recent
build?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
--- Comment #2 from pcarlini at suse dot de 2007-05-09 01:34 ---
I have a draft...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 01:45 ---
Here is a shorter testcase:
int
foo (void)
{
unsigned int resultvar;
long int arg = (long int) 0;
register long int reg asm (eax) = arg;
asm (nop
: =r (resultvar)
: 0 (reg)
);
return resultvar;
--- Comment #40 from gianni at mariani dot ws 2007-05-09 01:54 ---
Paolo writes:
... concur that string is better implemented without reference-counting ...
Could I ask you to enumerate the reasons why you come to this conclusion ? I
just want understand better why (royal) we came to
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
|
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 02:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 03:07 ---
Related to PR 29116.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31871
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 03:14 ---
I don't see a problem with this .. are two different tokens (.) so getting rid
of the space is ok here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-09 03:19 ---
That's why I think we should have a generic option that disables optimizations
which are safe only in sequential programs (and -fopenmp would imply that
option).
So it sounds like you don't any thing about
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-09 04:02
---
Apparently the magic limit here is 65535, not 10 as stated previously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #2 from neil at gcc dot gnu dot org 2007-05-09 05:01 ---
The space is required by the standard. Is this a regression? I believe GCC
used to get this right but I could be wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
79 matches
Mail list logo
