--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:09
---
(In reply to comment #3)
> I'm not yet sure how to deal with matmul, wether by
> converting its arguments or by creating kind=1 and
> kind=2 versions.
I think converting wil have a huge performance hit, so we'd b
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:11
---
Brooks, maybe it's time to backport them to 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30420
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:14
---
Time for a 4.2 backport?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 09:08
---
Created an attachment (id=13019)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13019&action=view)
Patch implementing the -fbacktrace option
Here's an updated version of the patch I submitted some time ago.
--- Comment #12 from brooks at gcc dot gnu dot org 2007-02-07 09:10 ---
(In reply to comment #7)
> If I read the F2003 standrad correctly, then
> your program conforms to F2003. You may want
> to change this to an enhancement request.
This is incorrect -- the code does not conform to
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-07 09:24 ---
Subject: Re: recursive I/O hangs under OSX 10.3
> Section 9.5.3.7.1, paragarph 2, defines a "child I/O statement" as one that's
> occuring within a user-defined derived-type I/O function -- which is
> definitely
>
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-07 09:47 ---
> Patch implementing the -fbacktrace option
I think one should add also some userhandler
signal(SIGSEGV, my_segv_handler);
which calls show_backtrace and exits/coredumps then.
That way we calso get a backtrace for
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-07 09:55 ---
note the size of class cls grows exponentially with its template parameter.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-07 09:58 ---
Confirmed. Note we already NULLify the pointer in the caller for
_gfortran_deallocate (but I missed to fix the comment before that function as
well).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
--- Comment #10 from hp at gcc dot gnu dot org 2007-02-07 10:09 ---
Subject: Bug 28870
Author: hp
Date: Wed Feb 7 10:09:41 2007
New Revision: 121684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121684
Log:
PR testsuite/28870
* testsuite/27_io/basic_stringbuf/o
--- Comment #11 from hp at gcc dot gnu dot org 2007-02-07 10:12 ---
Subject: Bug 28870
Author: hp
Date: Wed Feb 7 10:12:21 2007
New Revision: 121686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121686
Log:
PR testsuite/28870
* testsuite/27_io/basic_stringbuf/o
--- Comment #12 from hp at gcc dot gnu dot org 2007-02-07 10:16 ---
The checked-in changes marked with this PR don't solve the timeout issue by
far,
but hint of a way to solve timeout problems for specific tests, for specific
(classes of) systems, in another way than changing the default
--- Comment #3 from jakub at gcc dot gnu dot org 2007-02-07 12:16 ---
Subject: Bug 30703
Author: jakub
Date: Wed Feb 7 12:16:22 2007
New Revision: 121688
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121688
Log:
PR c++/30703
* gimplify.c (gimplify_scan_omp_clau
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-07 13:35 ---
Subject: Bug 28468
Author: jakub
Date: Wed Feb 7 13:35:17 2007
New Revision: 121689
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121689
Log:
2007-02-07 Bruno Haible <[EMAIL PROTECTED]>
config/
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-07 13:37 ---
Subject: Bug 30703
Author: jakub
Date: Wed Feb 7 13:37:29 2007
New Revision: 121690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121690
Log:
PR c++/30703
* gimplify.c (gimplify_scan_omp_clau
--- Comment #5 from jakub at gcc dot gnu dot org 2007-02-07 13:39 ---
Approved offline by Alex Oliva, committed so far on the trunk.
Will backport to 4.2 branch after a week or so on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
--- Comment #10 from jakub at gcc dot gnu dot org 2007-02-07 13:42 ---
Should be fixed on the trunk and 4.2 branch now, thanks Roger.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
Got the following error message when compiling gcc itself:
---
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="" \
/bin/sh ../../gcc-4.2-20070131/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="" \
HEADERS=
--- Comment #4 from tvb at gnome dot org 2007-02-07 14:59 ---
(In reply to comment #3)
> What is there to warn about?
> If you do -Winitialize without -O, you get a warning so ...
>
I just tried the explicit -Wuninitialized, very good,
and I noticed at least its documented in the man
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-07 16:39 ---
To me a warning should not be emitted while using -Wall -O0 as it will break
all the programs which use -Werror which is a lot of them. Also this is
already documented, if people don't read documentation, why would
--- Comment #12 from hhinnant at apple dot com 2007-02-07 16:46 ---
At the ad-hoc LWG meeting in Batavia, Jan 22-24, 2007, the LWG decided that
self referencing code in list::remove must work. Here is a preview of the
issue which is currently set to become official at the Spring '07 mee
--- Comment #6 from tvb at gnome dot org 2007-02-07 16:48 ---
(In reply to comment #5)
> To me a warning should not be emitted while using -Wall -O0 as it will break
> all the programs which use -Werror which is a lot of them. Also this is
> already documented, if people don't read docu
--- Comment #13 from hhinnant at apple dot com 2007-02-07 16:59 ---
(In reply to comment #12)
> If we have a utility similar to boost::address_of, that might be better than
> using operator& to get the address of the value_type (to accommodate types
> which overload operator&).
Oops, I
--- Comment #14 from chris at bubblescope dot net 2007-02-07 17:12 ---
Unless __value comes from the list, does the standard require
__a.address(__value) to work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
--- Comment #15 from hhinnant at apple dot com 2007-02-07 17:22 ---
(In reply to comment #14)
> Unless __value comes from the list, does the standard require
> __a.address(__value) to work?
>
That's a good question Chris. The way I read the current draft, I believe the
answer is no.
If you configure to build a 32-bit compiler on a 64-bit Linux system with:
CC='gcc -m32' /src/trunk/configure --{target,host,build}=i686-pc-linux-gnu ...
the compiler fails because it defaults to 32-bit code but the standard
assembler is 64 bit, and it fails in building libgcc. If you are building
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-07 17:52 ---
Hi FX,
> do you remember why always performing that check (ie, turn function to be
> always true) is not the right thing to do?
When working on this, I hit numerous testsuite regressions
when always checking for n
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-02-07 17:54 ---
> The status of the other patch is: Waiting for review.
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00260.html
I can't do any regression-testing right now, because PR 30678 :-(
--
http://gcc.gnu.org/bugzill
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 18:05 ---
It might be better to do something like powerpc64-linux-gnu does and define a
--with-cpu=default32 which compiles a 64bit capable compiler but defaults to
32bits.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-07 19:10
---
(In reply to comment #5)
> If you find something that works without that argument (which is
> a bit of a kudge), so much the better.
The patch I attached removes this argument, and it gives no regression on the
t
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 19:22
---
Created an attachment (id=13020)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13020&action=view)
Patch to not generate calls to internal_free any more
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=307
--- Comment #14 from dominiq at lps dot ens dot fr 2007-02-07 19:55 ---
The test is known to fail on OSX 10.3 (gcc 4.3.0 20070202) and 10.4 (PPC with
gcc 4.2.0 20070124
and MacIntel gcc unknown).
When I have filled the PR I have forgotten to say that the same bug was present
in
http://
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-02-07 20:05
---
According to http://gcc.gnu.org/ml/gcc/2007-02/msg00067.html,
this was caused by
2007-02-03 Bruce Korb <[EMAIL PROTECTED]>
* inclhack.def (glibc_c99_inline_4): replace "extern" only if
surrounded by
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-07 20:08 ---
> I think converting wil have a huge performance hit, so we'd better havec
> kind=1
> and kind=2 versions.
I agree, here's a patch to do this.
For speed reasons, we should also reverse the conversions
through the
#include
int f(int t, ...)
{
va_list a;
va_start (a, t);
va_arg(a, int);
int t1 = va_arg(a, int);
va_end(a);
return t1;
}
-
We get a warning on the line which just contains va_arg(a, int);
Even though the value is not used, a is still incremented so the result is not
unused afte
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30729
$ cat > warning.c
#if 0
gcc-4.1.1 -c -Os warning.c -Wunsafe-loop-optimizations
exit 0
#endif
void foo(unsigned int n)
{
while (n > 10)
n -= 2;
}
^D
$ sh warning.c
warning.c: In function 'foo':
warning.c:8: warning: cannot optimize loop, the loop counter may overflow
warnin
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-02-07 20:49 ---
(In reply to comment #6)
> The patch I attached removes this argument, and it gives no regression on the
> testsuite. I also simplified the conditional expression by using a COND_EXPR
> instead of generating differe
--- Comment #13 from bkorb at gnu dot org 2007-02-07 21:02 ---
The problem was supposed to have been fixed:
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00194.html
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00172.html
If you are still having problems, please show the nature of the difficulty.
--- Comment #3 from patchapp at dberlin dot org 2007-02-07 21:40 ---
Subject: Bug number PR target/29599
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00646.html
--
http://gcc.gnu.org/bug
--- Comment #3 from skottmckay at gmail dot com 2007-02-07 21:58 ---
Doesn't it need to be copy constructable for the rebinding to work for
_Vector_base::_Vector_impl::_Tp_alloc_type?
I agree that making it mt-safe doesn't quite fit with its intended usage.
Possibly the array_allocator
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-07 22:31
---
Reduced testcase:
enum, bind (c)
integer :: x
enumerator blue
end enum
end
It fails under valgrind for both i686-linux and x86_64-linux:
==5651== Invalid read of size 4
==5651==at 0x9DBD13: __
/home/apinski/src/fsf/gcc/gcc/libobjc/exception.c: In function
'parse_lsda_header':
/home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:94: warning: passing argument
2 of 'read_uleb128' from incompatible pointer type
/home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:103: warning: passing
argument 2 o
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 22:50 ---
Mine for both being the spu maintainer and the libobjc maintainer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26573
--- Comment #5 from dnovillo at gcc dot gnu dot org 2007-02-07 23:33
---
I cannot reproduce this bug with mainline as of 2007-02-06. The bug is still
latent though, so I will commit a variant of this patch to fix it.
Essentially, we should leave every TREE_ADDRESSABLE variable alone
--- Comment #9 from tobi at gcc dot gnu dot org 2007-02-08 00:44 ---
I reviewed the patch which introduced ENUM support, will take a look at this
tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-02-08 03:12
---
Try :
external fun
real fun
character(10) :: string
real a
a = fun()
print *, a,a
write(string,'(f10.6)') fun()
print *, string
end
real function fun()
print *, 'test'
fun = 1.0
end
Or increase the size of stri
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-08 07:32 ---
Seemingly fixed
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
52 matches
Mail list logo
