--- Comment #6 from Eric dot Doenges at betty-tv dot com 2006-04-26 06:26
---
Unfortunately, removing the __asm__ ("r0") from __r0 does not circumvent the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-26 06:22 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
> I wonder if this is a case of illegal code. Intel errors on "infinite
> format".
Well, current g95, ifort
It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and
GNU/Linux.
The following construct:
void *p;
((char *)p)++;
makes the compiler to issue an error message, namely
"invalid lvalue in increment"
The ((char *)p) construct is perfectly valid object, a char pointer which
c
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 04:10
---
I am not sure (emphasis on not sure) I agree with this. But I can explain what
it is doing. It is correctly printing out the letter 'n' then its looking for
the first data item and finds the integer in the list,
--- Comment #7 from sayle at gcc dot gnu dot org 2006-04-26 03:21 ---
Subject: Bug 26961
Author: sayle
Date: Wed Apr 26 03:20:56 2006
New Revision: 113266
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113266
Log:
PR target/26961
* fold-const.c (fold): When conv
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-26 02:44 ---
*** Bug 27280 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 2006-04-26 02:44 ---
*** This bug has been marked as a duplicate of 10894 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-26 02:40 ---
Did I mention this fails on powerpc-darwin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-26 02:27 ---
This works in the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321
Test code:
long double x = __builtin_infl();
int main() {
int r = x == __builtin_infl();
return r ? 0 : 1;
}
Commands to reproduce:
gcc -mlong-double-128 tc.c
./a.out && echo ok || echo fail
No problem with -mlong-double-64.
Cause:
GCC first transforms (x ==
--- Comment #94 from pinskia at gcc dot gnu dot org 2006-04-26 02:13
---
*** Bug 26846 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-04-26 02:13 ---
Oh, if you had put how you involved gcc in the comments instead of in build
script, I would have seen what the problem is.
Anyways this is a dup of bug 19664.
The problem is the libstdc++'s headers don't have push
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 00:56
---
My experiance has been that if you have gfortran installed from a distribution
such as Fedora and you build your own later version of gfortran from source and
you do not configure the later version to install in i
--- Comment #2 from janis at gcc dot gnu dot org 2006-04-25 23:49 ---
The patch that introduced this failure also causes the same ICE in several SPEC
CPU2000 programs on powerpc64-linux for "-O2 -fmodulo-sched" with either -m32
or -m64. I haven't tried the patch that was supposed to fix
--- Comment #4 from hbd_bugreports at earthlink dot net 2006-04-25 23:46
---
Subject: Re: C++ class object destructors are not called
for static class objects in a shared library when dlclose is called.
pinskia at gcc dot gnu dot org wrote:
>--- Comment #3 from pinskia at gcc do
--- Comment #5 from pr2345 at gmail dot com 2006-04-25 23:29 ---
The man page/online manual also needs a small clarification.
It only mentions the libmudflap library and not libmudflapth. I assume
a multithreaded program should link with -lmudflapth instead of -lmudflap?
Should I crea
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-25 22:14 ---
(In reply to comment #2)
> Subject: Re: C++ class object destructors are not called
> for static class objects in a shared library when dlclose is called.
> So You are telling me this is not a gcc problem but a
--- Comment #2 from hbd_bugreports at earthlink dot net 2006-04-25 22:07
---
Subject: Re: C++ class object destructors are not called
for static class objects in a shared library when dlclose is called.
So You are telling me this is not a gcc problem but a limitation in
CYGWIN.
This ICE happens after the error message with
$ cat gen.f90
module generic
interface foo
module procedure foo_real
end interface foo
contains
subroutine foo_real(a)
real :: a
end subroutine foo_real
end module generic
program main
use generic
call foo(1)
end program main
$ gfo
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-25 21:36
---
Patch applied to trunk.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-25 21:34
---
Subject: Bug 26725
Author: rsandifo
Date: Tue Apr 25 21:34:48 2006
New Revision: 113257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113257
Log:
gcc/
PR rtl-optimization/26725
* cfgrtl.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #9 from george dot chapman at lmco dot com 2006-04-25 21:32
---
*** Bug 27186 has been marked as a duplicate of this bug. ***
--
george dot chapman at lmco dot com changed:
What|Removed |Added
--
--- Comment #8 from george dot chapman at lmco dot com 2006-04-25 21:32
---
*** This bug has been marked as a duplicate of 26678 ***
--
george dot chapman at lmco dot com changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:31 ---
Yes, this is a target specific issue. If the target does not support atexit,
this is what will happen.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from george dot chapman at lmco dot com 2006-04-25 21:31
---
I agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
--- Comment #10 from janis at gcc dot gnu dot org 2006-04-25 21:16 ---
A regression hunt of trunk on powerpc-linux using mini.c with -O2 identified:
http://gcc.gnu.org/viewcvs?view=rev&rev=109016
r109016 | bonzini | 2005-12-23 16:07:53 + (Fri, 23 Dec 2005)
--
http://gcc.gnu.or
--- Comment #6 from rth at gcc dot gnu dot org 2006-04-25 21:03 ---
Fixed, or if not, moved the point of failure out of libgomp.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rth at gcc dot gnu dot org 2006-04-25 20:58 ---
Subject: Bug 25865
Author: rth
Date: Tue Apr 25 20:58:25 2006
New Revision: 113256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113256
Log:
PR libgomp/25865
* configure.ac: Use GCC_CHECK_TLS.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
For C++ classes of any type, the class destructor fails to be called under the
following circumstances in the CYGWIN environment (not a problem in linux):
1) A static object of a class is declared within the body of a function which
is part of a shared library.
2) The shared library is loaded wit
--- Comment #7 from brett dot albertson at stratech dot com 2006-04-25
19:29 ---
(In reply to comment #6)
> Fixed.
>
After this patch was applied onto trunk, the following test started failing on
Solaris x86:
FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump n \+ \-1
All the other
--- Comment #3 from dwarak dot rajagopal at amd dot com 2006-04-25 19:07
---
Yes this is true. The example I posted was a simplest case where it fails.
Below mmight be a typical case where you have to do two stores.
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:47 ---
Hmm, interesting, we have a TARGET_EXPR before gimplifying:
__asm__ __volatile__(""::"m" TARGET_EXPR - 1)];
} struct struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR - 1)];
};
struct
{
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:41 ---
Confirmed, the ICE is at least a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
You must be doing something wrong as I know this works for me and many other
people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
The other way of getting this is to have the code converted so there is only
one store instead of two:
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:31 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
Test case:
--
module test
implicit none
interface
subroutine hello(n)
integer :: n
end subroutine hello
end interface
end module test
subroutine hello(n)
integer, intent(in) :: n
integer :: i
do i = 1,n; print *, 'hello'; end do
end subroutine hello
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:43 ---
This is the not form for support for binaries. We only support GCC which was
been compiled by your self.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:41 ---
This works for me and many other people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:38 ---
Confirmed, if cvt should have a way to track if a memory write has happened.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:35 ---
(In reply to comment #5)
> Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now
> whether -fno-strict-aliasing makes the testcase valid is another question ;)
Nope, unaligned access is differen
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-25 17:28 ---
We need a testcase to go any further.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 ---
*** Bug 27276 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 2006-04-25 17:25 ---
Read PR 14704.
*** This bug has been marked as a duplicate of 14704 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-25 17:24 ---
Post scriptum:
I actually see two bugs here:
(a) for static format strings, the test should be done at the compile time
(possibly also for c = '(''n'')'; write(*,c) n )
-> see NAG compiler
(b) f
--- Comment #8 from aldot at gcc dot gnu dot org 2006-04-25 17:00 ---
Created an attachment (id=11334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11334&action=view)
fix typo in errormessage in verify_cgraph_node()
Just as a sidenote.. There is a typo in the error message in com
--- Comment #3 from eliot at sonic dot net 2006-04-25 16:44 ---
(In reply to comment #2)
> Can you try a snapshot of 4.1.1 and/or the mainline?
>
i tried mainline. same crash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
-ld=/mingw/bin/ld
--with-as=/m
ingw/bin/as --disable-werror --enable-bootstrap --enable-threads=win32
--with-wi
n32-nlsapi=unicode
Thread model: win32
gcc version 4.2.0 20060425 (experimental)
c:/program files/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/f951.exe
ch0
701.f90 -quiet -dumpbase ch0701.
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A {};
struct B : A
#pragma omp parallel
{};
struct B : A
#pragma omp parallel
{};
===
bug.cc:4: error: '#pragma' is not allowed here
bug.cc:5:
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A
#pragma omp parallel
{
template void foo();
};
template void A::foo<0>();
===
bug.cc:2: error: '#pragma' is not allowed here
bug.cc:7: er
Red Hat Enterprise Linux WS release 3 (Taroon Update 6) on Opteron:
bar [10:08:42] /baz > cat foo.f90
program foo
end program foo
bar [10:10:01] /baz > gfortran foo.f90 -Wl,-rpath,/scr_bar/johan/local/lib -o
foo
bar [10:10:24] /baz > ./foo
./foo: error while loading shared libraries: libgfortran.
--- Comment #9 from dje at gcc dot gnu dot org 2006-04-25 16:09 ---
By the way, while Andrew and my patch does produce correct code, it reverts to
the original behavior of the constant propagating into the AND between life2
and lreg, not between life1 and combine. Somehow combine is abl
--- Comment #2 from avi at argo dot co dot il 2006-04-25 15:57 ---
But why 24? gcc could place the object in any of the 12 bytes needed for stack
alignment.
I don't see any reason why the empty object needs to be aligned to more than a
byte boundary.
What am I missing?
--
http://g
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-04-25 15:55
---
Created an attachment (id=11333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11333&action=view)
updated patch
This is a cleanup of the patch by Jeff, bootstrapped and regtested on
x86_64-unknown-linux-gnu.
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 15:48 ---
The empty class has a size of 1. And yes, the ABI requires to preserve stack
alignment.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
A[k] = B+C;
g = D[k-1] + E[k-1];
if (g > A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In the above code, the if-then statement is not conver
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 15:45 ---
__res should be allocated to the same register as __r0 due to the '0'
constraint which tells gcc to use the same register as for "=r" (__res).
Whoops - I obviously meant to remove the __asm__("r0") from the __r0
var
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 ---
Grr. David's patch is also good. Perhaps better if we follow the usual
protocol of posting patches to gcc-patches *after* bootstrap and regression
testing, for review and approval. Posting untested patch fragments to
b
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 ---
Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could
not split insn
The patch may be necessary, but does not fix the testcase. The testcase
needs the patch that Andrew originally tested:
compiling the following
--start-code
struct X {
void g();
};
void g();
void f()
{
X x;
x.g();
g();
}
--end-code-
yields (with -O2)
subl$24, %esp
in the prologue. without the empty class only 12 bytes are subtracted,
presumably to preserve stac
--- Comment #4 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:43
---
Removing the __asm__ ("r0") from __res works around the bug - but then I cannot
depend on gcc
always allocating r0 for __res, can I ? I found no other way to tell gcc which
registers it must use.
I'm assuming
--- Comment #3 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:37
---
Storing the result to memory generates correct code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 14:29 ---
Changing the function to take both arguments as uint8_t* fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 14:27 ---
Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now
whether -fno-strict-aliasing makes the testcase valid is another question ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-25 14:23
---
This issue is related to PR22002. I have a patch.
A slightly-more reduced testcase is:
struct node { struct node *next; int value; };
struct node *current_node, global_list;
void
bar (void)
{
struct node *nod
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-25 14:23
---
Richard, you confirmed this.
But to me this looks like the code is violating the aliasing rules
(which would mean that the PR in invalid):
*(uint64_t *)dest = *(uint64_t *)src;
but
uint8_t *dest
const
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 ---
Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2
regression, probably due to the more aggressive RTL optimizations on mainline.
So I'll preapprove Paolo's fix for mainline (please post the version y
--- Comment #5 from walter dot zimmer at dlr dot de 2006-04-25 14:05
---
> The link-time wrapping of malloc is designed precisely so that other
> uninstrumented libraries that call malloc by name still get registered in the
> libmudflap runtime. That way, pointers from these libraries
--- Comment #7 from pcarlini at suse dot de 2006-04-25 13:33 ---
Yes, we are simply implementing the resolution of DR 103: set<>::iterator is a
constant iterator type
--
pcarlini at suse dot de changed:
What|Removed |Added
-
The following testcase causes a segfault in duplicate_eh_regions
when compiled with "-fopenmp -O":
==
struct A
{
~A();
};
struct B
{
A a1, a2;
};
void foo()
{
A x1, x2;
#pragma omp parallel
B b;
}
==
Reduced from Martin's test
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 13:23 ---
template
class set
{
...
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type::
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 ---
(In reply to comment #4)
> The standard doesn't mention set::erase with "iterator" argument, only with
> "const_iterator".
erm. the other way round, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 ---
The standard doesn't mention set::erase with "iterator" argument, only with
"const_iterator". Maybe it is legal for g++ to allow it anyway (even if I
cannot find anything in the standard allowing it at the moment), but other
The following invalid testcase causes an ICE since GCC 4.0.0:
=
struct A
{
int i;
A() i() {} // missing colon
};
struct B
{
A a;
};
B b;
=
bug.cc:4: error: expected ';' before 'i'
bug.cc:5: error: expected `;' before '
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:49 ---
This is probably a problem with the inline asm constraints. Try removing the
__asm__("r0") from the __res variable. Also try simplifying the testcase by
storing the result of BIOS_ContainerUsage(1) to memory rather
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** This bug has been marked as a duplicate of 27308 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** Bug 27305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1) \
static inline type name(type1 arg1) { \
register long __r0 __asm__
--- Comment #93 from rguenth at gcc dot gnu dot org 2006-04-25 12:21
---
*** Bug 27306 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 ---
.. to close as dup of PR21920.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:20 ---
Oh, this is just an aliasing issue. Reopening...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 ---
It's a valid C++ fragment. However, this code accesses "ptr", which is of type
void*, via an lvalue of type U16*. This is undefined behavior, so there is no
gcc bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:15 ---
This is not a valid testcase, or even expression. I guess it's invalid anyway
because of operator precedence.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:11 ---
Considering it. What happens?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:07 ---
Look at the assembly output of gcc (-S) and see if there is an appropriate
alignment directive before the entry for AMLogging in the bss section. If
there
is, the assembler/linker are at fault. Otherwise please att
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 11:55 ---
mainline doesn't do vectorization here:
/tmp/t.c:12: note: === vect_analyze_dependences ===
/tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24
and *dest.0_23
/tmp/t.c:12: note: bad data
--- Comment #2 from mehmet dot ekici at alcatel dot com dot tr 2006-04-25
11:49 ---
(In reply to comment #1)
> First, gcc 3.4.3 is no longer in active maintainance, the oldest still
> maintained version is 4.0.3. Second, please read the bugreporting guidelines
> and provide a testcase
1 - 100 of 118 matches
Mail list logo