I've got a Using and Porting GNU CC manual for rev 2.95, and am
looking around for a newer one and can't find it anywhere. Does
anyone know if a newer printed manual is available(and if so, where I
can find it)?
At the risk of stating the dreadfully obvious, the manual is online at
On 4/17/05, Jack Howarth [EMAIL PROTECTED] wrote:
Even if there were complete g77 compatibility in g95, folks may want
to stick with the g77 version from gcc 3.4 for awhile purely for
performance reasons. In doing some test runs of the APBS
Adaptive Poisson-Boltzmann Solver program, I
I have a chip which is developed by other lab.
It's VLIW architecture and it contains 2 RISCs and 8 DSPs.
The size of all registers are 32 bits.
There is a special instruction in the RISC which is called `movi' (move
immediate).
Its syntax and semantic are:
movilr1, #const (moves #const to
James Tabor wrote:
Hi!
I started resurrecting PowerPC WinNT GCC support, Ha! I'm running into
this atm.
/home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/
-B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem
/usr/powerpcle-pe/include -isystem
Steven J. Hill [EMAIL PROTECTED] wrote:
../sysdeps/ieee754/dbl-64/s_isinf.c:29: error: 'isinf' aliased to
undefined symbol '__isinf'
../sysdeps/ieee754/dbl-64/s_isinf.c:31: error: '__isinfl' aliased
to undefined symbol '__isinf'
../sysdeps/ieee754/dbl-64/s_isinf.c:32: error:
Hi,
while lacking the deep insight into GCC internals most of you have, I'd never
the less like to ask you to be very prudent concerning the issue of removal
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit targets, for 8 and 16 bit targets the RTL representation
possibly
On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
Hi,
while lacking the deep insight into GCC internals most of you have, I'd never
the less like to ask you to be very prudent concerning the issue of removal
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit
Steven J. Hill [EMAIL PROTECTED] wrote:
I have a working MIPS cross toolchain with:
binutils-2.15
gcc-3.4.2
glibc-2.3.4
linux-2.6.12
and then decided to work with gcc-4.1.0 out of the cvs head. I am now
getting build problems with glibc-2.3.4 with the first major snafu
being:
James E Wilson wrote
You shouldn't be trying to build your own types in a machine dependent
attribute handler function. The compiler's type system is determined by
front-ends mainly, and some middle-end infrastructure, and isn't your domain
to mess with. This stuff is subject to change, at
warning: initialization discards qualifiers from pointer target
type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
Otherwise I'll prepare patch.
Thanks,
-
Devang
const char *a( void )
{
return abc;
}
int main( void )
{
warning: initialization discards qualifiers from pointer target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
Otherwise I'll prepare patch.
const char *a( void )
{
return abc;
}
int main( void )
{
char *s =
Snapshot gcc-4.1-20050417 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050417/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-04-17 17:43 UTC
You'll find
You'll find that globally changing the rounding mode will screw up
libm functions. Which is pretty much going to make this useless.
OK. I didn't know that, and it's going to be annoying. So, the GNU libm
doesn't enable us to call mathematical function with non-default
rounding mode? IIUC, this
Mike Hearn [EMAIL PROTECTED] wrote:
I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4
based system. All of the C++ libraries it links directly against, like
GTKmm, are statically linked. In other words, it dynamically links
against no C++ libraries.
Inkscape dlopens
On Apr 17, 2005, at 10:37 PM, Gareth Pearce wrote:
So I just started trying out gcc 4.1 - with a program which compiles
and
runs fine on gcc 3.3.
Attached is a reduced testcase which shows runtime segfault due to
stack
overflow if compiled with 4.1 but does not with 3.3. Trivial work
around
FX Coudert wrote:
[attribution lost]
You'll find that globally changing the rounding mode will screw up
libm functions. Which is pretty much going to make this useless.
OK. I didn't know that, and it's going to be annoying. So, the GNU libm
doesn't enable us to call mathematical function
On Sun, Apr 17, 2005 at 07:48:53PM -0700, Gary Funck wrote:
This usage of a null substitution came up while I was trying to use
this form of spec. for a different switch, but the following illustrates
the problem using the existing gcc compiler as built for Redhat Linux
running on an SGI
Andrew Haley [EMAIL PROTECTED] writes:
Ranjit Mathew writes:
Geoffrey Keating wrote:
[...]
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Jason Merrill [EMAIL PROTECTED] writes:
On Thu, 14 Apr 2005 10:12:37 -0400, Michael N. Moran [EMAIL PROTECTED]
wrote:
Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.
As
Paul Koning [EMAIL PROTECTED] writes:
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave Original Message
From: Paul Koning Sent: 15 April 2005 17:56
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave Doesn't the C language spec require the mode to be switchable
Dave at
Joseph S. Myers [EMAIL PROTECTED] writes:
On Thu, 14 Apr 2005, Richard Henderson wrote:
On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote:
Does gcc support
#pragma STDC FENV_ACCESS
No, but we currently act like access is on.
I thought we acted like it is off,
On Sat, 16 Apr 2005, Richard Kenner wrote:
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and unroll/peel themselves.
I disagree. In order to make the proper
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
06:19 ---
Subject: Bug 20375
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-17 06:19:18
Modified files:
gcc: ChangeLog
gcc/config/alpha:
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17
06:24 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Apr 17, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
Mark, did you give up on
--
What|Removed |Added
Summary|[4.0/4.1 Regression] C++ ICE|[4.0 Regression] C++ ICE in
|in |assign_parm_find_entry_rtl
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:29
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01881.html
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:31
---
Subject: Re: too liberal operator lookup
Why are you pinging bugzilla, and not the list, wherein a c++
maintainer might see it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17805
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
06:37 ---
(In reply to comment #5)
Subject: Re: too liberal operator lookup
Why are you pinging bugzilla, and not the list, wherein a c++
maintainer might see it?
Actually he pinged both.
--
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:39
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
Target Milestone|4.0.1 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
06:51 ---
Subject: Bug 20693
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-17 06:51:12
Modified files:
libjava:
Compiling the following with GCC 3.4.3 (with gcc -O2 -S file.c)
float mul2(float a, float b) {
float v = -a * b;
return -v;
}
produce the erroneous code
pushl %ebp
movl%esp, %ebp
flds8(%ebp)
fmuls 12(%ebp)
popl%ebp
ret
where
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
07:34 ---
Note GCC does not know about the rounding mode, in fact the round mode is only
changeable in C99
by the #pragma which GCC does not do right now and I thought that is a
different PR already.
--
--- Additional Comments From charlet at adacore dot com 2005-04-17 08:13
---
Subject: Re: Warnings from init.c
I believe you can commit as obvious once tested.
Right.
There are other occurence of the same code for other target, but I don't have
access to them, may be Arnaud?
I
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-17
08:52 ---
Subject: Re: Excessive optimization of floating point
expression
pinskia at gcc dot gnu dot org wrote:
Note GCC does not know about the rounding mode,
This seems a good reason not to attempt
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-04-17
09:43 ---
I searched for 'extern C int printf' in the testsuite and all the other
declarations I saw are in line with my patch.
However, I believe that it is worth taking a cursory look at the ip2k function
--- Additional Comments From samedii at gmail dot com 2005-04-17 09:55
---
To solve this error, update the jdk14 port to patchset 7 (my was patchset 6) and
then compile like you would have otherwise.
Download the latest port from:
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-17 10:59
---
hppa64-hpux is indeed the only target I now see this failing on on
gcc-testresults.
--
What|Removed |Added
--- Additional Comments From joseph at codesourcery dot com 2005-04-17
11:04 ---
Subject: Re: [4.0/4.1 Regression] Miscompilation with
__attribute ((aligned))
On Sun, 17 Apr 2005, mark at codesourcery dot com wrote:
The obvious options include:
* Make a new type of larger
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
11:38 ---
Subject: Bug 15977
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-17 11:37:52
Modified files:
gcc:
The constructor String(strBytes, UTF-16LE); throws a
UnsupportedEncodingException which is not logical, becasue the Charset is
supported according to Charset.availableCharsets()
TestCase will follow. This is my output
Available Charsets are:
{ISO-8859-1=ISO-8859-1, US-ASCII=US-ASCII,
--- Additional Comments From gruni dot ca at gmail dot com 2005-04-17
12:43 ---
Created an attachment (id=8665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8665action=view)
Tests the String(strBytes, UTF-16LE); which shouldn't return an Exception
This is the testcase which runs
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-17
12:59 ---
According to Andrew, the
FAIL: Array_3 execution - gij test
FAIL: Array_3 execution - gij test
failures are expected: optimization is allowed to delete load insns whose
result is unused, even if those
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
14:30 ---
Subject: Bug 20914
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-17 14:30:37
Modified files:
libstdc++-v3 : ChangeLog
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15977
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
14:37 ---
(In reply to comment #1)
This is the testcase which runs without Exception in JDK but throws the
UnsupportedEncodingException when compiled with GCJ.
My system was WinXP with GCJ 4.0 from thisiscool.com
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
14:42 ---
(In reply to comment #2)
Then this is most likely the static linking bug.
In fact yes this is just the static linking problem, if anyone makes GCC make
shared libraries for GCC
that would be useful as
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
15:08 ---
Confirmed, reduced testcacse:
struct ff { ff(); int cmem(void) const; };
template typename T
int muv(T, int (T::*)(void));
template typename T
int muv(T, int (T::*)(void) const);
template typename T
int
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-04-17 15:21 ---
The work-around which forces inclusion of the needed class:
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
public class GcjStringTest {
static {
--- Additional Comments From theine at nordita dot dk 2005-04-17 15:22
---
Compilation of the following piece of code gives the same error message:
program test
character, dimension(2) :: a
integer :: i=1,j=2
--
What|Removed |Added
Summary|javax-imageio.lo failed to |[4.1 Regression] javax-
|build |imageio.lo failed to build
Target
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-17 16:08
---
Just got another bugreport for this bug, this time in gnomesword,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155152
The new references are created in tree-ssa-ccp.c's fold_stmt when it
constant
FAIL: gcc.dg/ia64-sync-1.c execution test
FAIL: gcc.dg/ia64-sync-2.c execution test
FAIL: gcc.dg/ia64-sync-3.c execution test
appeared on ia64-hpux on mainline on 20050417; immediately previously those
tests failed to compile (bug 21051). gcc-testresults indicates these tests also
FAIL on ia64
--
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.1.0
The patch
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00712.html
causes more than 1000 failures:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01089.html
The problem seems uniuqe to ia64. The good ones:
[EMAIL PROTECTED] libjava]$ readelf --wide -
sr
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
16:34 ---
Are you sure that this is not a linker problem.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-04-17 16:34
---
Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid
signed integers in the code. However, I'm not sure that someone will actually
do the work, given the soon-to-be-deprecated status of
--- Additional Comments From hjl at lucon dot org 2005-04-17 16:39 ---
I am investigating the ia64 linker. I think the ia64 linker should issue
an error if it can't get it to work at the run time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21070
--- Additional Comments From mark at codesourcery dot com 2005-04-17 17:04
---
Subject: Re: [4.0 Regression] ICE in cgraph_mark_reachable_node
jakub at gcc dot gnu dot org wrote:
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-17
16:08 ---
Just got
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17
17:06 ---
Joseph, RTH, and I all feel this should be invalid code. I think that's
consensus. So, I've updated the PR. Patches to actually issue a diagnostic
would be welcome.
--
What|Removed
--- Additional Comments From gruni dot ca at gmail dot com 2005-04-17
17:27 ---
Allright that solved this problem. Unfortunately I can not run the programm
anymore in JDK after adding the static. Is there a way to keep my sources
compatible with JDK and GCJ ?
Regrads
Andreas
--
/bin/sh ../libtool --tag CXX --tag disable-shared --
mode=link /export/build/gnu/gcc-next/build-ia64-linux/./gcc/xgcc -shared-
libgcc -B/export/build/gnu/gcc-next/build-ia64-linux/./gcc/ -nostdinc++ -
L/export/build/gnu/gcc-next/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-
v3/src
Issues with switching base allocator in so 6 inside attachment.
--
Summary: base allocator change shared object issues
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: libstdc++
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-04-17 17:56
---
Created an attachment (id=8666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8666action=view)
bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-04-17 17:57
---
Created an attachment (id=8667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8667action=view)
revert base allocator change
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-04-17 17:59
---
Additional fixes include adding _M_reclaim_block checks. However, this seems to
be patching the symptom, not the disease.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
--- Additional Comments From hjl at lucon dot org 2005-04-17 18:01 ---
.L_ZN4java4util7logging6Logger7getNameEv13 is a local alias of
_ZN4java4util7logging6Logger7getNameEv. When
_ZN4java4util7logging6Logger7getNameEv is discarded, I am trying
to figure out what happened to
Will attach patch.
--
Summary: Incorrect declaration of member variable in p3060d.C
testcase
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: testsuite
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-04-17
18:04 ---
Created an attachment (id=8668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8668action=view)
With callee cleanup, declarations must be correct
--
--- Additional Comments From hjl at lucon dot org 2005-04-17 18:06 ---
Ok, linkder did complain:
/usr/local/bin/ld: `.L_ZN4java4util7logging6Logger7getNameEv13' referenced in
section `.data.rel' of ./.libs/libgcj0_convenience.a(Logger.o): defined in
discarded section
--
What|Removed |Added
Component|middle-end |java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21070
--- Additional Comments From pcarlini at suse dot de 2005-04-17 18:16
---
This can be safely closed: in Lillehammer, the LWG moved the proposed resolution
of DR 467 to [Ready] (modulo a minor pasto in the first sentence) thus
explicitly
mandating the behavior implemented by v3.
--
--- Additional Comments From pcarlini at suse dot de 2005-04-17 18:27
---
Ick! :(
Actually, I clearly remember a message from Mark warning that something could go
wrong when using different allocators in different sources, but then forgot
about the issue when we switched. I really hope
Hi,
I found a little bug in the implementention of the method
getHeaderFieldKey( int index ) in the file
java/net/protocol/http/HTTPURLConnection.java.
This method doesn't check if the parameter 'index' if out of range, so if it
is called with a index value too high a
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21074
--- Additional Comments From hjl at lucon dot org 2005-04-17 19:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01915.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21070
239 241 243 245 247 249 251 253 255
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050417 (experimental)
--
Summary: Segfault in reshape with rank
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
20:27 ---
Subject: Bug 21075
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-17 20:26:57
Modified files:
libgfortran: ChangeLog
libgfortran/m4 :
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-17
20:29 ---
Fixed in 4.1, waiting for 4.0 to reopen.
--
What|Removed |Added
DETECTED==+
| 4.1.0 20050417 (experimental) (i686-pc-linux-gnu) GCC error: |
| in set_value_range, at tree-vrp.c:124|
| Error detected at cxg2009.adb:421:5 |
/home/guerby/work/gcc/build
--
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
Component|ada
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17
21:07 ---
Subject: Bug 16032
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcjx-branch
Changes by: [EMAIL PROTECTED] 2005-04-17 21:07:22
Modified files:
gcjx :
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-17
21:13 ---
It's a target problem: FreeBSD overrides this line from sparc.h:
#define CPP_SPEC %(cpp_cpu) %(cpp_arch) %(cpp_endian) %(cpp_subtarget)
with this line from freebsd-spec.h:
/* Provide a CPP_SPEC
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-17 21:28
---
On HEAD this doesn't fail any longer because of the:
* final.c (output_addr_const): Do not call mark_referenced.
change (part of tree profiling branch merge).
I don't think you can construct a C testcase for
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
21:34 ---
Confirmed, just a note the patch which fixes this on the mainline is wrong as
shown by PR 20965.
--
What|Removed |Added
--- Additional Comments From mark at codesourcery dot com 2005-04-17 21:52
---
Subject: Re: [4.0 Regression] ICE in cgraph_mark_reachable_node
jakub at gcc dot gnu dot org wrote:
some reachable function, cgraph will know about it. The OBJ_TYPE_REF is
special
in that there is no
When reworking the testsuite setup for AVR, I have stepped of the following
missed optimization:
The avr target does fail for the following test case
(gcc.c-torture/execute/20020720-1.c) with reporting a link error:
Question: After filing this bug report should I post a patch marking the
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-17 22:25
---
Binary search on ia64-hpux shows the failure appeared between 2005-03-22 22:04
UTC and 2005-03-22 22:30 UTC. The only plausibly responsible patch in that
range is
2005-03-22 Zdenek Dvorak [EMAIL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:27 ---
*** Bug 21077 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:27 ---
This is a dup of bug 20139.
And yes just xfail the testcase as this one is known to not pass a lot of
places.
*** This bug has been marked as a duplicate of 20139 ***
--
What|Removed
Test case gcc.c-torture/excecute/20010122-1.c fails the execution tests for
optimization levels -O1, -O2, -O3-g and -Os while passing for -O0. Tests were
run with simulavr for the atmega128.
I do not have a clear opinion about what is going wrong. The fact that the test
passes for -O0 is
tests gcc.c-torture/excecute/ffs-1 and -2 fail since neither libgcc nor libgcc2
provide support for the excpected builtin function ffs.
--
Summary: avr-gcc lacks support for builtin ffs function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
Excecution of gcc.c-torture/excecute/pr17377.c fails for optimization level
-O0 and passes for other optimizer switches: Somewhat suspicious.
--
Summary: Excecution test failure for avr for pr17377 test case.
Product: gcc
Version: 4.1.0
Status:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:45 ---
ffs is a POSIX function which almost all libc provides.
So if there is no fall back function, there is nothing which GCC can do.
Does avr have instructions which could be used to implement this if so it
--
What|Removed |Added
OtherBugsDependingO||21080
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:47 ---
This looks like the same cause as PR 21078 since both use
__builtin_return_address.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17
22:56 ---
Confirmed, ifcvt introduces the invalid gimple.
--
What|Removed |Added
CC|
1 - 100 of 130 matches
Mail list logo
