The following shows a problem on the Alpha whereby
the division 2/3 made on floats is flagged as exact.
Here are the details:
$ cat sf.cc
#include
#include
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf("%d %.1000g\n", fetestexcept(FE_INEXACT) !=
--- Comment #1 from bagnara at cs dot unipr dot it 2008-09-19 07:04 ---
Created an attachment (id=16359)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16359&action=view)
Assembly code generated with g++ -S -mieee-with-inexact sf.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
gcc is complaining about an ambiguous overloading of operator&&
in the statement (last non-trivial line)
return std::pow(a,2.0);
where no such operator appears. (I haven't seen a macro definition of 'pow'
which pulls in '&&')
If I replace the statement above by
return ::pow(a,2.0);
the e
--- Comment #1 from jarausch at igpm dot rwth-aachen dot de 2008-09-19
07:33 ---
Created an attachment (id=16360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16360&action=view)
preprocessed failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
--- Comment #2 from jarausch at igpm dot rwth-aachen dot de 2008-09-19
07:35 ---
gcc -v -save-temps -c TEST3.C
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/
Reported by Arjen Markus.
http://gcc.gnu.org/ml/fortran/2008-09/msg00327.html
The following program causes an ICE ("insert_bbt(): Duplicate key found!") when
compiled with gfortran 4.1 to 4.4.
a) The unmodified program seems to be invalid as NAG f95 and ifort show:
Error: ENTRY point GLOCAL is
--- Comment #14 from uros at gcc dot gnu dot org 2008-09-19 08:02 ---
Subject: Bug 37544
Author: uros
Date: Fri Sep 19 08:01:07 2008
New Revision: 140484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140484
Log:
PR rtl-optimization/37544
* regrename.c (maybe_mod
--- Comment #1 from burnus at gcc dot gnu dot org 2008-09-19 08:18 ---
Not only as actual argument also as direct procedure call, gfortran misses the
recursive call to ENTRY:
subroutine sub()
return
entry glocal()
call glocal () ! << wrong: Recursive call
end subroutine
And a simpl
--- Comment #1 from jpr at csc dot fi 2008-09-19 08:20 ---
Small update: this bug is already present in 4.3.1.
The 4.2.x series seems OK.
Juha
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-19 08:36 ---
Indeed ;) Honza, mention this PR in the changelog please.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pault at gcc dot gnu dot org 2008-09-19 09:00 ---
Hah! I never did like ENTRY in Modules:-(
Changing the actual argument reference to 'glocal' to appear after the ENTRY,
by use of a GOTO, allows the horror below to run correctly.
Thus, in the reporter's version, th
--- Comment #3 from sam at gcc dot gnu dot org 2008-09-19 09:05 ---
Could you try a more recent GCC version and check whether the bug is still
present or not? It compiles fine with GCC 4.3.1 on x86_64/Debian GNU/Linux.
--
sam at gcc dot gnu dot org changed:
What|Remov
--- Comment #2 from jpr at csc dot fi 2008-09-19 09:25 ---
This invalid peace of code gives an ICE:
program test
integer, pointer :: a(:),b(:)
a(1) => b(1)
end program test
gfortran -c test.f90
test.f90: In function 'test':
test.f90:3: internal compiler error: in gimplify_expr, at
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-19 09:34 ---
Shorter testcase:
#include
class super_real {
public:
super_real (double);
};
bool operator&& (int i, const super_real& a);
double square(double a) {
return std::pow(a,2.0);
}
--
rguenth at gcc dot g
--- Comment #15 from uros at gcc dot gnu dot org 2008-09-19 10:06 ---
Subject: Bug 37544
Author: uros
Date: Fri Sep 19 10:04:46 2008
New Revision: 140487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140487
Log:
PR rtl-optimization/37544
* regrename.c (maybe_mod
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-19 10:12 ---
program test
real, pointer :: a(:), b(:)
a(:) => b(:)
end program test
That program is invalid.
R735 pointer-assignment-stmt
is data-pointer-object [ (bounds-spec-list) ] => data-target
or data-poi
--- Comment #16 from ubizjak at gmail dot com 2008-09-19 11:11 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
Unfortunately there is no simple testcase for this,
but compiling mplayer I get a lot of crashes related to
stack corruption
i.e. a function allocates in the stack 8 bytes
and later gdb says that it cannot access to a byte that instead is bound
I've tested with --stack-size on the linker but
--- Comment #4 from singler at gcc dot gnu dot org 2008-09-19 11:38 ---
Subject: Bug 37470
Author: singler
Date: Fri Sep 19 11:37:16 2008
New Revision: 140490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140490
Log:
2008-09-19 Johannes Singler <[EMAIL PROTECTED]>
PR
--- Comment #5 from singler at gcc dot gnu dot org 2008-09-19 11:44 ---
Fixed.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #37 from b0ntrict0r at yandex dot ru 2008-09-19 12:22 ---
Created an attachment (id=16361)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361&action=view)
Updated patch
Could someone test updated patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
On trunk at Thu Sep 18 22:45:12 UTC 2008 (revision 140476)
$ gnatchop ../trunk/gcc/testsuite/ada/acats/support/rep*
$ gnatchop ../trunk/gcc/testsuite/ada/acats/tests/c6/c650001.a
$ gnatmake -gnat95 -f -O1 c650001.adb
...
gnatlink c650001.ali
./c650001.o: In function `_ada_c650001':
c650001.adb:(.
--- Comment #4 from bitti at iki dot fi 2008-09-19 12:12 ---
(In reply to comment #3)
> Similar to Bug 15764.
I ran again into this bug in gcc 4.3.2. Any idea when there's time to fix it?
Matti Rintala
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
--- Comment #4 from jdecs at mssblue dot net 2008-09-19 13:03 ---
(In reply to comment #3)
> Could you try a more recent GCC version
I can try. The last time I tried to find updates to GCC, GIT, and GNAT, there
were dependency problems on 64 bit systems.
I have also been in touch with T
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:17
---
It's a fallout of the recent changes to the inlining machinery.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from b0ntrict0r at yandex dot ru 2008-09-19 13:18 ---
(In reply to comment #0)
This keyword seems to be Microsoft specific, right?
--
b0ntrict0r at yandex dot ru changed:
What|Removed |Added
--
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:18
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #9 from amacleod at redhat dot com 2008-09-19 13:27 ---
Created an attachment (id=16362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16362&action=view)
patch to fix the bug
Looking a little closer, Im going to change Honza's patch a little. Since the
checks are no lo
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-19 13:33 ---
Created an attachment (id=16363)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16363&action=view)
Fix for both aspects of PR
The bit in decl.c fixes the duplicate key business and that in resolve.c flags
up the
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 13:58 ---
The problem is const_vector_from_tree called on:
unit size
align 32 symtab 0 alias set -1 canonical type 0x7332d540
precision 32 min max
pointer_to_this >
V4SI
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-19 14:12 ---
vect_get_vec_def_for_operand has:
tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
int nunits = TYPE_VECTOR_SUBPARTS (vectype);
...
/* Case 1: operand is a constant. */
case vect_constant_def:
...
f
--- Comment #3 from anhvofrcaus at gmail dot com 2008-09-19 14:23 ---
On the second attempt to build gcc-4.4-20080912 using the latest binutils along
with gmp-4.2.2 and mpfr-2.3.2, this problem goes away. In summary, GNAT works
fines now.
Additional note: c, ada, and c++ languages are b
Hi,
I have tried various OpenMP examples on the web and got them all to work fine.
When I tried to parallelize some software that is part of a larger project, I
have had a problem; OpenMP reports only one processor available and so I get
only 1 thread. More details follow.
I am running on an dual
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43 ---
"I tried setting the environment variable OMP_NUM_THREADS to 2 and got 2
threads, but only one processor was running the job."
this suggests your operating system is limiting your job to one CPU.
--
rguenth at g
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-09-19 15:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-09-19 15:06
---
Subject: Bug 36343
Author: rguenth
Date: Fri Sep 19 15:04:36 2008
New Revision: 140492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140492
Log:
2008-09-19 Richard Guenther <[EMAIL PROTECTED]>
gfortran -v
GNU Fortran (GCC) 4.4.0 20080919 (experimental)
[~/tmp]$gfortran test.f90 -floop-block -O2
test.f90: In function 'main':
test.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.
--- Comment #4 from anhvofrcaus at gmail dot com 2008-09-19 15:24 ---
/home/voax/linux/build-4.4.0/./prev-gcc/xgcc
-B/home/voax/linux/build-4.4.0/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmiss
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-19 16:00 ---
This regression is caused by compare/branch fuse optimization.
Gcc 4.3 is OK. Turn it off fixes it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 16:01 ---
Caused by http://gcc.gnu.org/viewcvs?view=rev&revision=140415
C++ FE has a weird habit of sticking error_mark_node in DECL_INITIAL, in this
case in finalize_nrv_r:
if (DECL_INITIAL (dp->var)
&& DECL_INI
read model: posix
gcc version 4.4.0 20080919 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic'
/usr/local/gnutest/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 gen-type-bound.f03
-quiet -dumpbase gen-type-bound.f03 -mtune=generic -auxbase gen-type-bound
-ver
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-19 16:39 ---
Created an attachment (id=16364)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16364&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
The following failures
FAIL: objc.dg/stubify-1.m (test for excess errors)
ERROR: objc.dg/stubify-1.m: error executing dg-final: couldn't open
"stubify-1.s": no such file or directory
FAIL: objc.dg/stubify-2.m (test for excess errors)
FAIL: objc.dg/stubify-2.m scan-rtl-dump-not jump "symbol_ref.*"o
--- Comment #2 from rrpeter at sandia dot gov 2008-09-19 16:59 ---
Subject: Re: OpenMP thinks that I have 1 processor
on an 8 processor pc
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43
> ---
> "I tried setting the
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-19 17:02 ---
Self-contained testcase, which will work even for non-ascii compatible
exec-charset:
/* PR tree-optimization/37573 */
struct S
{
unsigned int *a;
unsigned int b;
unsigned int c[624];
};
static unsigned char __
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 17:37 ---
FWIW -- on trunk, debug_str is controlled by -fmerge-debug-strings,
which is enabled by default (on supporting platforms).
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from amacleod at redhat dot com 2008-09-19 17:38 ---
Subject: Bug 37567
Author: amacleod
Date: Fri Sep 19 17:37:13 2008
New Revision: 140494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140494
Log:
PR middle-end/37567
* tree-ssa-ter.c (free_tem
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-19 17:42 ---
I'm closing this.
It is fixed on mainline and is not apparently a regression.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-19 17:52 ---
The data dependence on the previous loop is clearly not considered, the loop is
vectorized as if c on the rhs and c on the lhs were different non-overlapping
arrays.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Consider this code:
#include
std::string s;
I compiled this with -g and examined the resulting dwarf.
's' is represented as:
<1><24e8>: Abbrev Number: 63 (DW_TAG_variable)
<24e9> DW_AT_name: s
<24eb> DW_AT_decl_file : 1
<24ec> DW_AT_decl_line : 3
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-19 18:03 ---
(In reply to comment #1)
> Root cause is that instruction length of fused jcc is set to 16, which prevent
> the block from merging and copying. For some reason Core2 runs poorly with a
> unmerged branch block under c
Sent from my iPhone
On Sep 19, 2008, at 10:58 AM, "tromey at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
Consider this code:
#include
std::string s;
I compiled this with -g and examined the resulting dwarf.
's' is represented as:
<1><24e8>: Abbrev Number: 63 (DW_TAG_variable)
<24e
--- Comment #1 from pinskia at gmail dot com 2008-09-19 18:11 ---
Subject: Re: New: g++ should emit different debug info for variable's type
Sent from my iPhone
On Sep 19, 2008, at 10:58 AM, "tromey at gcc dot gnu dot org"
<[EMAIL PROTECTED]
> wrote:
> Consider this code:
>
> #i
In a case such as this, GCC ought to be able to prove that the signed variable
is positive and therefore suppress "signed and unsigned" warnings. I see this
in both C and C++.
#define MAX(a,b) ((a) > (b) ? (a) : (b))
#define MIN(a,b) ((a) < (b) ? (a) : (b))
unsigned int
constrain(unsigned int in
--- Comment #2 from jason at redhat dot com 2008-09-19 18:14 ---
Subject: Re: [4.4 regression] ICE returning
a struct
jakub at gcc dot gnu dot org wrote:
> IMHO either we relax the checking, allowing DECL_INITIAL to be error_mark_node
> even for !TREE_STATIC, or finalize_nrv_r would n
--- Comment #5 from janis at gcc dot gnu dot org 2008-09-19 18:24 ---
The operand of a postincrement and friends must be a modifiable lvalue. The
type check code for both C and C++ calls get_unwidened, which removes the cast
when it's a different size but leaves the cast when it's the s
--- Comment #7 from dominiq at lps dot ens dot fr 2008-09-19 18:32 ---
Although I know this is not the right way to fix pr34310 I have done the
following change to /usr/include/objc/Protocol.h:
--- /usr/include/objc/Protocol.h-orig 2008-09-19 17:16:42.0 +0200
+++ /usr/include/
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 18:59 ---
Consider this code:
#include
std::string zardoz1;
using std::string;
string zardoz2;
In this case, IMO, 'whatis' should print 'std::string' for zardoz1,
but just 'string' for zardoz2.
This is simply not possible
When compiling certain complex calculation files I'm getting the message:
/a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:
In member function 'void NLM_hicumshxpm::CModel::calcDer(NLM_hicumshxpm*,
double*, CDer<13u, double, const double, CDerHe
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-19 20:07 ---
I believe the program is valid [modulo the CLASS/TYPE issue].
(NAG f95 by the way give an odd error message and crashes than with a
segfault.)
--
burnus at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-19 20:17 ---
I'll take this on as it is about GENERIC type-bound procedures.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from peter_foelsche at agilent dot com 2008-09-19 20:39
---
sorry -- I did discover the matching option to increase memory.
--
peter_foelsche at agilent dot com changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-19 20:41 ---
Also it is not just about memory but also compile time. GCSE (PRE) is O(BBs *
Regs).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
$ cat c.c
void blurb(void)
{
}
$ mips-linux-gcc -O2 -S -fno-pic -mno-abicalls c.c
$ cat c.s
.file 1 "c.c"
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.text
.align 2
.globl blurb
.entblurb
.type blurb, @func
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 20:53 ---
*** This bug has been marked as a duplicate of 25763 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-19 20:53 ---
*** Bug 37589 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 20:55 ---
I think this needs to delay the warning until VRP time really but I don't see
how that can be done really.
Also the front-end does known that adj will only be positive, the middle-end
only knows during VRP really.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 21:03 ---
We really need a testcase. And I really doubt -ftree-ch is causing any issues,
there must be a latent bug in the back-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from zackw at panix dot com 2008-09-19 21:28 ---
I'd be fine with it being like uninitialized value warnings. The false
positives here are *really* annoying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
--- Comment #4 from tromey at gcc dot gnu dot org 2008-09-19 21:38 ---
FWIW -- I think this patch turned out to have some GC-related bug.
And, I don't think I need this for the incremental branch either, any more.
So, I'm just dropping it and closing this.
If someone else wants to clean
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-19 21:45 ---
As already said in the openmp.org forum, omp_get_num_procs () will only return
smaller number than the number of system CPUs online, if GOMP_CPU_AFFINITY env
var is used, or if the calling process and/or thread has CPU
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
--- Comment #4 from rrpeter at sandia dot gov 2008-09-19 22:01 ---
Subject: Re: OpenMP thinks that I have 1 processor
on an 8 processor pc
jakub at gcc dot gnu dot org wrote:
> --- Comment #3 from jakub at gcc dot gnu dot org 2008-09-19 21:45 ---
> As already said in the open
--- Comment #6 from janis at gcc dot gnu dot org 2008-09-19 22:19 ---
Created an attachment (id=16365)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16365&action=view)
minimized C testcase
I don't yet understand what's going on but was able to come up with a
relatively small execu
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-09-19 22:24
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-19 22:25
---
Subject: Bug 30930
Author: pinskia
Date: Fri Sep 19 22:24:06 2008
New Revision: 140501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140501
Log:
2008-09-19 Andrew Pinski <[EMAIL PROTECTED]>
PR
Using this test code:
// #define _FILE_OFFSET_BITS 64
// #include
// #include
// extern "C" int __REDIRECT (open, (__const char *__file, int __oflag, ...),
open64)
// __nonnull ((1));
extern "C" int open (__const char *__file, int __oflag, ...) __asm__
("open64");
extern "C" int
open(cons
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 22:42 ---
open64 in this case is defined twice in the assembly.
You said that open is open64 via:
extern "C" int open (__const char *__file, int __oflag, ...) __asm__
("open64");
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from sje at cup dot hp dot com 2008-09-19 23:01 ---
I am not sure what I would be reviewing. Alexander, do you want me to review
the patch from comment #4 as a fix for this bug or is there another patch you
would like to propose to bring the ia64 sel-sched changes over.
I got this ICE when compiling rpm 5.1.4.
Detailed gcc output:
gcc -v -save-temps -DHAVE_CONFIG_H -I. -I.. -I../..
-DMAGIC=\"/Programs/RPM/5.1.4/lib/rpm/magic\" -DHAVE_LIBZ=1 -O3 -pipe
-mcpu=cell -maltivec -mabi=altivec -fomit-frame-pointer -MT funcs.lo -MD -MP
-MF .deps/funcs.Tpo -c funcs.c -fPIC
--- Comment #9 from vmakarov at gcc dot gnu dot org 2008-09-19 23:24
---
Subject: Bug 37535
Author: vmakarov
Date: Fri Sep 19 23:23:34 2008
New Revision: 140504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140504
Log:
2008-09-19 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #1 from giamby at infinito dot it 2008-09-19 23:26 ---
Created an attachment (id=16366)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16366&action=view)
.i preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37595
--- Comment #7 from janis at gcc dot gnu dot org 2008-09-20 00:26 ---
Sigh. My nifty small C testcase doesn't fail with current mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
In this testcase:
template
struct A
{
template void f();
template void g();
};
template
struct B
{
A a;
template void f();
void h()
{
a.f();
a.g();
}
};
we currently accept the call to a.f, but reject the call to a.g. It seems that
we're doing unqualified lookup tha
--- Comment #1 from daney at gcc dot gnu dot org 2008-09-20 00:38 ---
This may be an ABI issue, but since -mlong-calls -mno-abicalls doesn't seem to
have a very rigorous ABI definition, we probably have some latitude with
respect to implementing this.
foo.c:
--
extern int a;
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 00:41 ---
I think this is a duplicate of bug 11814.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37596
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-20 02:56 ---
*** This bug has been marked as a duplicate of 10200 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-20 02:56
---
*** Bug 20308 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-20 02:57 ---
Also PR 10200 which shows a rejects valid testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37596
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 03:06 ---
Well this is an accepts invalid code since it "compiles" at -O0 when it should
not. The ICE is during scev analysis.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-20 03:09 ---
This is a bug in the front-end ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|--- |4
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 03:12 ---
This is a regression as 4.3 enables the vectorizer at -O3. This is just one
example of where tuning is still needed for the vectorizer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||compile-time-hog
Summary|Hang for -O3|[4.4
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 Regression] Vectorizer |[4.3/4.4 Regression]
|is causing code bloat and |
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Status|UNCONFIRMED |WAITING
1 - 100 of 102 matches
Mail list logo
