--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-07 06:41 ---
there is also seems like some compile time problem.
In 4.1.2:
tree operand scan : 7.11 (16%) usr 0.22 (12%) sys 7.42 (16%) wall
2354 kB ( 2%) ggc
Though on the mainline even with checking:
tree operand
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-07 06:16
---
*** Bug 29375 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-07 06:16 ---
Yes this is a dup of bug 23372.
*** This bug has been marked as a duplicate of 23372 ***
--
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.2.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
--- Comment #8 from uros at kss-loka dot si 2006-10-07 06:12 ---
Testcase was commited to trunk and 4.1 branch, and now passes everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
-
--- Comment #2 from deft at thunkers dot net 2006-10-07 05:14 ---
(In reply to comment #1)
> cc: Internal error: Killed (program cc1)
>
> This means you ran out of memory while running cc1. The kernel killed cc1 so
> we cannot do a better job at the error message.
>
Ok. It compiles f
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 05:04 ---
cc: Internal error: Killed (program cc1)
This means you ran out of memory while running cc1. The kernel killed cc1 so
we cannot do a better job at the error message.
--
pinskia at gcc dot gnu dot org changed:
cc: Internal error: Killed (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
make: *** [opcodeiz.o] Error 1
The source files used are at http://deft.thunkers.net/priv/asmsh_mod.tgz
C
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-07 04:05 ---
(In reply to comment #2)
>
> Also, are you saying that the fix for PR23372 also brings us back to avoiding
> direct calls to memcpy?
No just the duplicated memcpy. not inlining memcpy is most likely not a bug,
jus
--- Comment #3 from deb at pixar dot com 2006-10-07 04:01 ---
Oops, I see how to get the patch. Never mind that part of the question,
thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
--- Comment #2 from deb at pixar dot com 2006-10-07 04:00 ---
(In reply to comment #1)
> I think this was fixed in 4.0.4 by the patch which fixed PR 23372.
>
For various reasons, upgrading to 4.0.4 isn't an option at this time.
(a) How do I obtain the specific patch you are referring t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 03:50 ---
I think this was fixed in 4.0.4 by the patch which fixed PR 23372.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.4.0 3.3.3 3.2.3 3.0.4 |3.4.0 3.3.3 3.2.3 3.0.4
|2.95.3 4.2.0
Using built-in specs.
Target: x86_64-redhat-linux-gnu
Configured with: ../gcc-4.0.3/configure x86_64-redhat-linux-gnu
--with-ld=/pixar/d2/sets/tools-03/bin/ld
--with-as=/pixar/d2/sets/tools-03/bin/as --prefix=/pixar/d2/sets/tools-03
--exec-prefix=/pixar/d2/sets/tools-03 --bindir=/pixar/d2/sets/tool
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-10-07 02:04 ---
(In reply to comment #6)
> > > There is mpfr_get_ld(), which converts to a long double. If the data type
> > > never exceeds the properties of long double, then one may be able to
> > > use mpfr_get_ld() and then fold
--- Comment #12 from geoffk at apple dot com 2006-10-07 00:28 ---
Subject: Re: builtin functions should use $LDBL128 suffix on darwin when
appropriate
"howarth at nitro dot med dot uc dot edu" <[EMAIL PROTECTED]> writes:
> Any chance you or Mike could take a stab at patching this bug
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2006-10-06
23:54 ---
Geoff,
Okay. Any chance you or Mike could take a stab at patching this bug in
time for gcc 4.2?
Jack
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #2 from lucier at math dot purdue dot edu 2006-10-06 23:31
---
On Darwin you can't compile the PPC64 version of _num.c, an even smaller file,
with Apple's gcc 4.0.1, and I can't build a 64-bit version of 4.2 to test it.
Blah.
gcc -mcpu=970 -m64 -I../include -I. -no-cpp-pre
The program below works for the Solaris and Microsoft compilers, but not for
the GCC compiler. Can anybody else verify this, and or if it's already been
fixed?
I'm using:
-bash-3.00$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr
--- Comment #1 from lucier at math dot purdue dot edu 2006-10-06 23:06
---
Created an attachment (id=12394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12394&action=view)
macro-expanded test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29374
--- Comment #10 from geoffk at gcc dot gnu dot org 2006-10-06 23:05 ---
(In reply to comment #9)
> Geoff,
> Are the variadic functions really worth worrying about? Currently gcc
> trunk
> can only
> be built with the cctools from Xcode 2.4 or later (which basically limits the
> buil
ssage.
euler-7% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/pkgs/gcc-mainline --disable-checking
--enable-languages=c
Thread model: posix
gcc version 4.2.0 20061006 (experimental)
With modulo-scheduling:
euler-6% gcc -I../include -I. -Wal
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-06 22:55 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-06 22:55 ---
Subject: Bug 29278
Author: tromey
Date: Fri Oct 6 22:55:24 2006
New Revision: 117521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117521
Log:
PR libgcj/29278:
* Makefile.in: Rebuilt.
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06
22:46 ---
Geoff,
Are the variadic functions really worth worrying about? Currently gcc trunk
can only
be built with the cctools from Xcode 2.4 or later (which basically limits the
builds to
MacOS X 10.4 machines
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2006-10-06 21:51
---
Fixed by the above patch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2006-10-06 21:45
---
Subject: Bug 29128
Author: mkuvyrkov
Date: Fri Oct 6 21:45:13 2006
New Revision: 117515
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117515
Log:
2006-10-06 Maxim Kuvyrkov <[EMAIL PROTECTED]>
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #5 from tobi at gcc dot gnu dot org 2006-10-06 21:01 ---
Actually this is invalid code. The string lengths in the constructor are
different, even though they have to be the same. See 4.5 in the F95 standard.
--
tobi at gcc dot gnu dot org changed:
What|R
--- Comment #5 from jason at gcc dot gnu dot org 2006-10-06 21:00 ---
Yes, sorry, I should have said if foo::bar is used in multiple TUs, rather than
foo itself. If foo::bar is defined in only one TU, and is used as an opaque
type in other TUs, you're fine.
Perhaps we should suppress t
(this is a spinoff of PR29267)
[EMAIL PROTECTED]:~/src/pr/29267> cat t.f90
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
print *, a
CONTAINS
CHARACTER(32) FUNCTION to_string(x)
REAL, INTENT(in) :: x
WRITE
--- Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37 ---
Another interesting variation:
[EMAIL PROTECTED]:~/src/pr/29267> cat t.f90
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
END PROGRAM
[EMAIL PROTE
--- Comment #3 from tobi at gcc dot gnu dot org 2006-10-06 20:36 ---
Slightly reduced testcase, gives the same ice:
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
a = resh
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-10-06 19:32
---
Subject: Bug 29256
Author: rakdver
Date: Fri Oct 6 19:32:04 2006
New Revision: 117513
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117513
Log:
PR middle-end/29256
* tree-ssa-loop-ivopts.
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-06 19:21 ---
Created an attachment (id=12391)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12391&action=view)
proposed patch
This patch makes the crash go away.
The bug is that strip() unconditionally uses 'stylesheet', b
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-10-06 19:20 ---
The general problem here is that on PPC Darwin, when using gcc with
-mlong-double-128 (which is the default), some system functions (you can find a
list in bug 25850) need to have $LDBL128 appended to their assembly n
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-10-06 19:18
---
I'm following up to the mailing list in the PR trail, since it's very confusing
to go back and forth between the two.
The technical issue is that in the following code:
extern "C" {
typedef void (*p1)();
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-10-06 19:16 ---
*** Bug 23504 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #4 from geoffk at gcc dot gnu dot org 2006-10-06 19:16 ---
Tracking this as part of the general problem under 25477.
*** This bug has been marked as a duplicate of 25477 ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-10-06 19:14 ---
*** Bug 25850 has been marked as a duplicate of this bug. ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from geoffk at gcc dot gnu dot org 2006-10-06 19:14 ---
This is entirely a dup of 25477.
*** This bug has been marked as a duplicate of 25477 ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from eplondke at gmail dot com 2006-10-06 19:07 ---
Changing the cost of (REG) to 1 fixes 4.1 but not 4.2, it seems.
In 4.2, the RTL optimization does not combine
ldr r2, [r1, #0]
ldr r3, [r0, #0]
add r0, r0, #4
add r1, r1
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se
2006-10-06 18:48 ---
I still fail to understand why this would inherently violate the ODR.
I agree with Andrew that if more than one translation unit sees the defintion
of foo::bar then it will violate the ODR but if
--- Comment #3 from jason at gcc dot gnu dot org 2006-10-06 18:36 ---
Yes. If foo is used in multiple translation units, it violates the ODR because
gazonk is a different type in each translation unit.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-06 18:15 ---
Andrew fixed this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 17:19 ---
We still need the sync-2.c testcase, Uros, can you please commit it?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 17:17 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 17:07 ---
Subject: Bug 28924
Author: jakub
Date: Fri Oct 6 17:06:52 2006
New Revision: 117511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117511
Log:
PR target/28924
* builtins.c (expand_builtin_sync
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-06 17:03 ---
> > There is mpfr_get_ld(), which converts to a long double. If the data type
> > never exceeds the properties of long double, then one may be able to
> > use mpfr_get_ld() and then fold_convert() the result to the pr
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 16:57 ---
Subject: Bug 29330
Author: jakub
Date: Fri Oct 6 16:57:27 2006
New Revision: 117509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117509
Log:
PR tree-optimization/29330
* tree-data-ref.c (fre
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 16:54 ---
Subject: Bug 28924
Author: jakub
Date: Fri Oct 6 16:54:43 2006
New Revision: 117508
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117508
Log:
PR target/28924
* builtins.c (expand_builtin_sync
--- Comment #7 from pcarlini at suse dot de 2006-10-06 16:07 ---
(In reply to comment #6)
> try again.
Certainly I can confirm that the problem cannot be reproduced anymore by
tweaking the random seed to 1153519516.
> the thing about (now) throw_allocator is that if some of the testcas
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-10-06 15:36 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> >> (In reply to comment #0)
> >>>
> > idea of what mpfr can do. My main area of concern right now is converting
> > between gcc's REA
--- Comment #5 from eplondke at gmail dot com 2006-10-06 14:55 ---
Here's what's going on in this case:
CSE changes an address if:
A) The cost of the address is lower
or
B) The cost of the address is the same and the cost of the RTX would be
higher outside of an address
So
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-06 14:40 ---
(In reply to comment #3)
> (In reply to comment #2)
>> (In reply to comment #0)
>>>
>>> 1. Whether a certain minimum version of GMP/MPFR is required to
>>> avoid known bugs, etc.
>> See my recent patch to toplevel co
The following program coredumps at nullify() when compiled with -fbounds-check,
otherwise it does work as supposed. If I remove one of the nullify()s or remove
the loop, it works ok.
-
program test
implicit none
type projector_t
real, pointer :
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-10-06 13:25 ---
(In reply to comment #2)
> (In reply to comment #0)
> >
> > 1. Whether a certain minimum version of GMP/MPFR is required to avoid known
> > bugs, etc.
> See my recent patch to toplevel configure.in. THe minimum requ
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-06 13:09 ---
Fixed also on the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-06 13:07 ---
Subject: Bug 28450
Author: pinskia
Date: Fri Oct 6 13:06:56 2006
New Revision: 117502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117502
Log:
2006-10-06 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-06 12:59 ---
As I understand it, the warning is because if you have the definition of class
foo::bar, you will be violating ODR for foo.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from andreas dot knuepfer at tu-dresden dot de 2006-10-06
12:40 ---
Would it be feasible to pass a different function address for inlined
functions? In particular, it should not be the same address as the parent
function.
I seem to recall that in previous versions (2.95
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-06 12:32 ---
Oh dear, yes.
Thank you, Tobi.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-10-06 11:51 ---
Fixed everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from paolo at gcc dot gnu dot org 2006-10-06 11:48 ---
Subject: Bug 29368
Author: paolo
Date: Fri Oct 6 11:48:34 2006
New Revision: 117498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117498
Log:
2006-10-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #2 from paolo at gcc dot gnu dot org 2006-10-06 11:48 ---
Subject: Bug 29368
Author: paolo
Date: Fri Oct 6 11:48:18 2006
New Revision: 117497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117497
Log:
2006-10-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #1 from paolo at gcc dot gnu dot org 2006-10-06 11:48 ---
Subject: Bug 29368
Author: paolo
Date: Fri Oct 6 11:47:56 2006
New Revision: 117496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117496
Log:
2006-10-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
AssignedTo|jakub at gcc dot gnu do
This is really a minor issue: There is an error in doxygen comments for rfind()
family functions, in file include/bits/basic_string.h. "@param pos" is wrongly
documented. It reads:
"* @param pos Index of character to start search at (default 0)."
while it should be:
"* @param pos Index of chara
--- Comment #6 from pcarlini at suse dot de 2006-10-06 11:14 ---
I'm reassigning to Benjamin...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-06 10:41 ---
try again.
the thing about (now) throw_allocator is that if some of the testcases have
allocated memory and then an exception is thrown, the "leaked" memory is
actually testsuite-type temporaries that should have been
--- Comment #7 from markus dot schoepflin at comsoft dot de 2006-10-06
10:23 ---
Created an attachment (id=12390)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12390&action=view)
Patch for mips-tfile.c against 4.1.1 source tree.
This turned out to be a bug in mips-tfile.c, trigge
for 4.2 versions of the policy-based associated containers, the individual
debug macros were stripped out and the usual libstc++-designating-debug-mode
macro was used.
This is: _GLIBCXX_DEBUG.
While doing this, I found a long-standing issue with the pb_ds hash-based
containers and the debug mod
The atomics configury for sh in libstdc++ is quite poor, and duplicates the
generic atomicity files if __SH4A__ is undefined. This is the only cpu
directory to do this, and leads to issues when the genric atomicity code is
updated: twice now the sh config has been left behind. This is no good. Let
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #4 from pcarlini at suse dot de 2006-10-06 09:59 ---
Fixed for 4.1.2 and 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASS
--- Comment #3 from paolo at gcc dot gnu dot org 2006-10-06 09:58 ---
Subject: Bug 29354
Author: paolo
Date: Fri Oct 6 09:58:03 2006
New Revision: 117495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117495
Log:
2006-10-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #2 from paolo at gcc dot gnu dot org 2006-10-06 09:57 ---
Subject: Bug 29354
Author: paolo
Date: Fri Oct 6 09:57:43 2006
New Revision: 117494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117494
Log:
2006-10-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-10-06 09:55 ---
I don't think this is an ordering problem... there are no complicated ordering
issues in this code. Something to try might be making test_mutex static, and
not in an anonymous namespace.
I'm not quite sure why hppa i
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-10-06 09:52 ---
When you get to "break here" this is what your mutex should look like in gdb:
Breakpoint 2, add () at lock_test.cc:14
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 1, __count = 0, __owner = 14845,
__k
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-10-06 09:48 ---
// try this simpler code.
#include
#include
namespace
{
__gnu_cxx::__mutex test_mutex;
unsigned int i;
} // anonymous namespace
void* add(void*)
{
__gnu_cxx::__scoped_lock sentry(test_mutex);
{
++i; //
--- Comment #4 from uros at kss-loka dot si 2006-10-06 08:27 ---
Please note, that in addition to
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00250.html,
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00244.html is also needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:42 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:42 ---
Fixed on 4.1 branch and on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 07:41 ---
Fixed on the trunk and on 4.1 branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2006-10-06 07:39 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #4 from jakub at gcc dot gnu dot org 2006-10-06 07:37 ---
Subject: Bug 29290
Author: jakub
Date: Fri Oct 6 07:37:04 2006
New Revision: 117487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117487
Log:
PR tree-optimization/29290
* tree-loop-linear.c (
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 07:35 ---
Subject: Bug 29198
Author: jakub
Date: Fri Oct 6 07:35:45 2006
New Revision: 117486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117486
Log:
PR target/29198
* config/i386/i386.c (legitimize_
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 07:33 ---
Subject: Bug 28415
Author: jakub
Date: Fri Oct 6 07:33:34 2006
New Revision: 117485
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117485
Log:
PR fortran/28415
* trans-decl.c (gfc_finish_var_d
--- Comment #3 from jakub at gcc dot gnu dot org 2006-10-06 07:27 ---
Subject: Bug 29290
Author: jakub
Date: Fri Oct 6 07:27:28 2006
New Revision: 117484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117484
Log:
PR tree-optimization/29290
* tree-loop-linear.c (
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:25 ---
Subject: Bug 29198
Author: jakub
Date: Fri Oct 6 07:25:02 2006
New Revision: 117483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117483
Log:
PR target/29198
* config/i386/i386.c (legitimize_
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 07:23 ---
Subject: Bug 28415
Author: jakub
Date: Fri Oct 6 07:23:00 2006
New Revision: 117482
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117482
Log:
PR fortran/28415
* trans-decl.c (gfc_finish_var_d
--- Comment #4 from jakub at gcc dot gnu dot org 2006-10-06 07:16 ---
Subject: Bug 29091
Author: jakub
Date: Fri Oct 6 07:15:48 2006
New Revision: 117481
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117481
Log:
PR c/29091
* varasm.c (output_constant): If TREE_
--- Comment #7 from patchapp at dberlin dot org 2006-10-06 07:02 ---
Subject: Bug number PR19261
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/2006-10/msg00281.html
--
http://gcc.gnu.org/bugzilla/sh
95 matches
Mail list logo
