--- Comment #2 from manu at gcc dot gnu dot org 2008-02-07 07:44 ---
Regressions need a target milestone, otherwise they don't appear in the list of
regressions.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--
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 #6 from tbm at cyrius dot com 2008-02-07 06:48 ---
I can confirm that this has been fixed. Thanks a lot.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #15 from kargl at gcc dot gnu dot org 2008-02-07 06:26 ---
(In reply to comment #14)
> Yes this is a regression wrt g77 and I have noted this in the summary. I have
> attempted to insert a mutex_unlock in the right place and it has no effect. I
> think jpr's assessment is c
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-02-07 06:07
---
Yes this is a regression wrt g77 and I have noted this in the summary. I have
attempted to insert a mutex_unlock in the right place and it has no effect. I
think jpr's assessment is correct, there needs to be a
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-07 05:10 ---
Revision 132088:
http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00100.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from jpr at csc dot fi 2008-02-07 05:07 ---
Subject: Re: I/O leaks handles/memory on Windows XP
>
> --- Comment #12 from tkoenig at gcc dot gnu dot org 2008-02-06
21:49 ---
> Just wondering... is this a regression?
At least g77 runs the two examples (in comm
--- Comment #19 from ismail at pardus dot org dot tr 2008-02-07 04:49
---
Even 20080104 snapshot fails, I have no idea why this only one test fails and
all other pass though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
Gcc 4.3 revision 132153 failed to compile:
[EMAIL PROTECTED] build_base_o2.]$ cat x.cc
#include
template
class Vector
{
};
template
class Foo
{
public:
virtual void foo (const unsigned int);
struct Data
{
std::vector > bar;
};
};
template
void Foo::foo (const unsig
--- Comment #18 from ismail at pardus dot org dot tr 2008-02-07 03:12
---
I started a reghunt with 20080104 snapshot, if that fails too I am out of ideas
why this happens. But I am sure this is the second time I see this file failing
but later on its fixed so I thought it was noise.
Th
--- Comment #8 from janis at gcc dot gnu dot org 2008-02-07 02:04 ---
Some experimentation shows how GCC is passing and returning non-hardware
vectors for powerpc*-linux:
-m32 (for trunk and 4.0)
pass struct by reference (copy in caller's frame)
return struct in memory using address
--- Comment #17 from manu at gcc dot gnu dot org 2008-02-07 00:12 ---
Try dropping "--enable-checking=release" from your configure. Or alternatively,
finding out on which revision it broke by doing a regression hunt. If you need
help with the latter, mail me privately and I will explain
--- Comment #20 from hjl dot tools at gmail dot com 2008-02-07 00:04
---
FYI, stack alignment branch will look like
if (TREE_STATIC (decl))
return (alignment <= MAX_OFILE_ALIGNMENT);
else if (MAX_VECTORIZE_STACK_ALIGNMENT)
{
gcc_assert (!cfun->stack_realign_proces
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-02-06 23:04
---
See also http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00195.html
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dgregor at gcc dot gnu dot
|
Rebuilding gcc rev. 132160 from scratch failed with:
...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defi
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-02-06 22:31
---
Even shorter testcase that doesn't trigger a warning:
===
struct A
{
~A() throw();
void foo();
};
struct B
{
B() { A().foo(); }
};
void bar()
{
#pragma omp parallel
{
#pragma
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-02-06 21:55 ---
Patch installed, fixed.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-02-06 21:51 ---
Subject: Bug 35107
Author: ghazi
Date: Wed Feb 6 21:51:24 2008
New Revision: 132160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132160
Log:
2008-02-06 Kaveh R. Ghazi <[EMAIL PROTECTED]>
PR other
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-02-06 21:49
---
Just wondering... is this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-06 21:49 ---
Untested, just happened to read the manual cited below.
Index: lang.opt
===
--- lang.opt(revision 132097)
+++ lang.opt(working copy)
@@ -25,13
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Running the testsuite on i386-unknown-freebsd6.2 I noticed the following:
=== libgomp Summary ===
# of expected passes 88
# of unexpected failures 731
# of unsupported tests109
(Cf. http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00301.html for detail
[EMAIL PROTECTED] g++]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../g++
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/g++.dg/ext/vector13.C
-nostdinc++
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unkn
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-06 21:14 ---
This works for me on the trunk, I don't get an ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-06 21:09 ---
The testcase works for me with a cross from x86_64, but - you mention g77 but
this is C preprocessed source. Is it the correct testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-06 21:00
---
It's also very dubious, as on my native i686 machine this works for me as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-06 20:58 ---
Confirmed.
If you remove the second #pragma omp single in
if( s == 0 ) {
#pragma omp single
#pragma omp single
{
for( LearnerBase * i = learners[0]; s == 0; ) {
if( os ) i->getIn
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-02-06 20:56
---
Even shorter testcase:
==
void foo()
{
struct A
{
friend class B;
};
B::B() {}
}
==
This is similar to PR34912.
--
reichelt at gcc dot gnu dot org changed:
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-06 20:55
---
It looks like for some reason the tree-reassoc pass did different things.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from jpr at csc dot fi 2008-02-06 20:54 ---
Subject: Re: I/O leaks handles/memory on Windows XP
I had a look: the problem seems to be with the logic of mutex->counter in
gcc/config/i386/gthr-win32.c. Libgfortran makes the following calls
during an internal write
1)
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-06 20:52
---
Before we make this anything but P3 I'd like to know whether this is
ice-on-valid
or ice-on-invalid (at least the original testcase never built without errors
for
me).
--
rguenth at gcc dot gnu dot org changed:
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-02-06 20:51
---
P2 - this should not block the release (it's not that profiledbootstrap was
never
broken in released compilers). It's also hard to analyze (no, I'm not on it,
volunteers welcome).
--
rguenth at gcc dot gnu dot
--- Comment #10 from andreast at gcc dot gnu dot org 2008-02-06 20:46
---
Committed after ok from Tom T. and a verification install from Dave A.
Thanks.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from andreast at gcc dot gnu dot org 2008-02-06 20:46
---
Subject: Bug 30071
Author: andreast
Date: Wed Feb 6 20:45:21 2008
New Revision: 132159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132159
Log:
2008-02-06 Andreas Tobler <[EMAIL PROTECTED]>
P
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-06 20:44 ---
(overriding Jakub, this ICE is not seen w/o checking)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35112
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 20:44 ---
Confirmed.
Do we have a separate bug about the 'tree_list' not supported error? If not
please open one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35112
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-06 20:41 ---
You should not build inside the source directory, do
mkdir obj
cd obj
../configure
make
instead. And quote also the gcc invocation from the internal compiler error.
You may also want to try gcc 4.2.3 which was jus
--- Comment #10 from jrp at dial dot pipex dot com 2008-02-06 20:39 ---
The latest checkins seem to have removed the following failure!
FAIL: g++.dg/conversion/simd3.C (test for errors, line 13)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35047
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-06 20:39 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 20:36 ---
Works for me with 4.3-20080202.
*** This bug has been marked as a duplicate of 33880 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-06 20:36 ---
*** Bug 35108 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #21 from aoliva at gcc dot gnu dot org 2008-02-06 20:34 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from aoliva at gcc dot gnu dot org 2008-02-06 20:33 ---
Err, mine ;-)
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-06 20:33 ---
Technically this is a regression. Not linking against unneeded libraries will
speed up dynamic loading as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107
--- Comment #19 from aoliva at gcc dot gnu dot org 2008-02-06 20:32 ---
Subject: Bug 35056
Author: aoliva
Date: Wed Feb 6 20:31:43 2008
New Revision: 132158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132158
Log:
gcc/cp/ChangeLog:
PR c++/35056
* tree.c: Include tree-flow.h.
--- Comment #10 from Jerry_V_DeLisle at rl dot gov 2008-02-06 20:25 ---
Reply to comment #9:
This is a very important observation. I have checked the code and we have code
that free's the internal unit (free_internal_unit) and I have confirmed that it
is called correctly after every wr
--- Comment #3 from yalbasilva at gmail dot com 2008-02-06 20:25 ---
Hi,
Yes, I had a typo when I included $JAVA_HOME/include/linux. Once I fixed it I
was able to compile OK.
Thanks for looking into this so quick! This can be closed.
--
yalbasilva at gmail dot com changed:
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-02-06 20:24 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|--- |4.1.3
h
The following invalid testcase triggers a broken error message
('tree_list' not supported by dump_decl) and an ICE since GCC 4.1.0:
namespace X { struct A; }
namespace Y { struct A; }
namespace Z { struct A; }
using namespace X;
using namespace Y;
using namespace Z;
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-02-06 19:22
---
Yes, there are number of unlucky variables. However the real source is here
seems to be always wrong profile guiding regalloc to optimize for cold portions
of the function rather than real increase of register pres
--- Comment #7 from vonbrand at inf dot utfsm dot cl 2008-02-06 19:12
---
(In reply to comment #6)
> Yes and I just mentioned why this case is incorrect. :)
>
> Anyways we had an "undocumented extension" (which means it was a bug) in GCC
> before 4.2 with this respect.
What is the poi
--- Comment #21 from ubizjak at gmail dot com 2008-02-06 19:10 ---
(In reply to comment #20)
> Since -fo-f-p adds another free reg, it looks that since inlining increases
> register pressure some unlucky heavy-used variable gets allocated to the stack
> slot.
It is "best_len" (and pro
--- Comment #4 from schwab at suse dot de 2008-02-06 19:05 ---
*** Bug 35110 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #1 from schwab at suse dot de 2008-02-06 19:05 ---
*** This bug has been marked as a duplicate of 13903 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from brossob at yahoo dot com 2008-02-06 18:54 ---
just did
./configure
and then
make.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35103
--- Comment #2 from brossob at yahoo dot com 2008-02-06 18:53 ---
i installed gcc3.4.6 from the sun freeware site.
and i just invoked make without any arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35103
--- Comment #12 from dgregor at gcc dot gnu dot org 2008-02-06 18:50
---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #11 from dgregor at gcc dot gnu dot org 2008-02-06 18:49
---
Subject: Bug 35049
Author: dgregor
Date: Wed Feb 6 18:49:03 2008
New Revision: 132152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132152
Log:
2008-02-06 Douglas Gregor <[EMAIL PROTECTED]>
PR
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-06 18:49 ---
Subject: Bug 35096
Author: dgregor
Date: Wed Feb 6 18:49:03 2008
New Revision: 132152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132152
Log:
2008-02-06 Douglas Gregor <[EMAIL PROTECTED]>
PR c
the below code snippet compiles using gcc 3.3.1 but fails to compile with gcc
4.1.1 giving the error
error: void* my_alloc::operator new(size_t, char*, int) may not be declared
within a namespace
- namespace_operator_new.cpp
#include
using std::bad_alloc;
using std::nothr
--- Comment #20 from ubizjak at gmail dot com 2008-02-06 18:42 ---
Whoa, adding -fomit-frame-pointer brings us from
(gcc -O3 -m32)
user0m41.031s
to
(gcc -O3 -m32 -fomit-frame-pointer)
user0m30.006s
Since -fo-f-p adds another free reg, it looks that since inlining increases
re
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-06 18:38 ---
This is invalid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Key
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in lookup_name_real, at |[4.3 Regression] ICE in
|cp/name-lookup.c:4056
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:34
---
Created an attachment (id=15112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15112&action=view)
failing test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
Fall-out from PR 35099:
g++ -c test2.ii
test2.ii: In member function typename vector<_Tp, _Alloc>::iterator
vector<_Tp, _Alloc>::insert(__normal_iterator, const _Tp&):
test2.ii:13: internal compiler error: in lookup_name_real, at
cp/name-lookup.c:4056
Please submit a full bug report,
That is
With gcc version 4.3.0 20071218, with this file:
$ cat test.f90
PROGRAM Outer
IMPLICIT NONE
REAL, DIMENSION(100) :: A
INTEGER :: k
!$OMP PARALLEL DO PRIVATE(k)
DO k=1,SIZE(A)
END DO
!$OMP END PARALLEL DO
CONTAINS
SUBROUTINE Inner
IMPLICIT NONE
A(k)=0.0D0
END SUBROUTINE In
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-06 18:30 ---
Yes and I just mentioned why this case is incorrect. :)
Anyways we had an "undocumented extension" (which means it was a bug) in GCC
before 4.2 with this respect.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from vonbrand at inf dot utfsm dot cl 2008-02-06 18:25
---
Created an attachment (id=15111)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15111&action=view)
A testcase showing the inconsistency
realf and realg should behave the same, but compiling gives an error on
--- Comment #4 from vonbrand at inf dot utfsm dot cl 2008-02-06 18:23
---
(In reply to comment #3)
> I still don't understand what you are asking? Do you have an example of where
> the differences comes into play? The only one I Know of is taking the address
> of the function, The def
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-06 18:18 ---
How did you configure GCC? How did you invoke make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2008-02-06 18:16 ---
I agree that the behavior should be the same for any non-hardware vector that
is passed or returned. That includes vectors that are different sizes from
hardware vectors, and vectors that are the same size as hardware
During bootstrap, GCC links all host programs with -lgmp -lmpfr. Only the
compiler itself (cc1, cc1plus, jc1, etc) need to do this. The other programs
(xgcc, gcj, cpp, gcov, jcf-dump, etc) don't need it. With static libs it
doesn't matter, but for shared libs it hooks in the .so file at runtime
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-06 18:10 ---
I still don't understand what you are asking? Do you have an example of where
the differences comes into play? The only one I Know of is taking the address
of the function, The default argument case cannot be assig
--- Comment #2 from danglin at gcc dot gnu dot org 2008-02-06 18:10 ---
It turns out these failures are a result of using the 2.0n ABI
with gmp-4.2.2. This is the default for hppa2.0w-hp-hpux11.11.
In all my previous testing, I had built GMP using the standard
1.x ABI. Using the 2.0n A
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:05
---
Created an attachment (id=15110)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15110&action=view)
fairly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-02-06 18:04
---
This also ICEs on valid code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rth at gcc dot gnu dot org 2008-02-06 17:38 ---
Created an attachment (id=15109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15109&action=view)
fix, try 2
"I see," said the blind man.
It turns out that the emission of the libcall had been responsible for
co
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-06
17:29 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00120.html
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #14 from ismail at pardus dot org dot tr 2008-02-06 17:01
---
I tried building without BOOT_CFLAGS and such but no luck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-02-06 16:56
---
Created an attachment (id=15108)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15108&action=view)
Complete continue heuristic patch
Hi,
this is the complete patch. With this patch we produce profile sane en
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-02-06 16:44
---
Created an attachment (id=15107)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15107&action=view)
Path to predict_paths_leading_to
Hi,
I've revived the continue heuristic patch. By itself it does not help b
--- Comment #3 from zadeck at naturalbridge dot com 2008-02-06 16:26
---
The dataflow changes caused, at least, the latest level of messing this up by
splitting, combining and removing a large number of passes without regard to
this antiquated system of naming the passes.
if the cons
--- Comment #2 from vonbrand at inf dot utfsm dot cl 2008-02-06 16:22
---
(In reply to comment #1)
> What are you trying to say?
If I declare:
void f();
void f(int);
or
void f(int i = 100);
should behave exactly the same way. If not, what is the point of offering
default argu
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 16:15 ---
log2 is part of C99 which C++ does not know about. C++ only knows about C89
routines in math.h.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-06 16:11 ---
What are you trying to say?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
You can define functions as overloaded or with default arguments. For the user
of the defined function, if it is defined by overloading or by default
arguments should be completely indifferent.
--
Summary: Unconsistent handling of overloaded vs default arguments
to
--- Comment #10 from ilmarw at simula dot no 2008-02-06 15:37 ---
Can confirm this on 32-bit platform as well:
Linux multiboot 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686
GNU/Linux
gcc version 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
I recompiled after patching as suggested above, s
--- Comment #7 from hjl at gcc dot gnu dot org 2008-02-06 15:23 ---
Subject: Bug 34921
Author: hjl
Date: Wed Feb 6 15:22:35 2008
New Revision: 132148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132148
Log:
gcc/
2008-02-06 Joey Ye <[EMAIL PROTECTED]>
PR middle-end
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-02-06 15:18 ---
*** Bug 35096 has been marked as a duplicate of this bug. ***
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-06 15:18 ---
This is the comptypes issue dealt with in PR 35049. I've verified that the fix
for that issue handles this test case, too.
*** This bug has been marked as a duplicate of 35049 ***
--
dgregor at gcc dot gnu dot o
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
Looks like last remaining problem is the missed loop invariant motion due to
STACK_REGS hack as in the case of pr23322
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2/gcc$ time
./a.out-nostackregs-hack
real
--- Comment #28 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
*** Bug 23305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #1 from nowak2000 at poczta dot onet dot pl 2008-02-06 15:00
---
Created an attachment (id=15106)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15106&action=view)
gnatchop concatenated sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35105
gnatmake -Pxxx/taskman.gpr taskman.adb -d
gcc-4.1 -c -g -g -gnat05 -gnatwc -gnatwd -gnatwi -gnatwj -gnatwp -gnatwr
-gnatVc -gnatVi -gnatVm -gnatVr -I- -gnatA xxx/tasks.adb
+===GNAT BUG DETECTED==+
| 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubu
I found this bug in cygwin's gcc, but it is probably
general problem.
#include fails to undefine math.h's macro log2.
I personally thinks, that like other math functions,
log2 shoud be function in namespace std, not macro.
(Bug found, when I was defining own int log2(int) function
in class)
--
--- Comment #13 from ubizjak at gmail dot com 2008-02-06 14:11 ---
I think that following difference is the key:
In case vectorizer is able to vecotrize, we enter vectorizer pass with:
:
# ivtmp.17_1 = PHI
# i_18 = PHI
# s_17 = PHI
D.2002_7 = a[i_18];
D.2003_8 = i_18 + D.2
1 - 100 of 143 matches
Mail list logo
