The most visible ongoing effort is the conversion from target macros
to target hooks (which is incomplete). The goal was to allow hot
swapping of backends. This is still the most obvious, most complete,
and least unappealing (from a technical POV) approach IMHO. But Kaveh
showed at one
Hi every one,
I would like to do backend work to convert OpenMP to GPGPU
langauages(Brook+).
could you please send me pointers to documents which explains the
source code details for OpenMP backend code generation?
As side point, I am very new to GCC development.
Thanks in
Hi,
I would like to do backend work to convert OpenMP to GPGPU
langauages(Brook+).
I'm not sure this would be best suited for backend work. The OpenMP
pragma expansion is done very early and the decision to offload parts
of the computation to the GPGPU would probably need to be taken before
, the best way
is to take a look at the code in gcc/omp-low.c
As side point, I am very new to GCC development.
Welcome then :)
Antoniu
__ NOD32 3947 (20090319) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
Hello All,
The current SVN tree contain two branches on plugins.
% svn info svn://gcc.gnu.org/svn/gcc/branches/plugin
Path: plugin
URL: svn://gcc.gnu.org/svn/gcc/branches/plugin
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID:
[Naganna] I would like to know all phases of GCC OpenMP(Paser level,
intermediate reprsentation, code generation and OpenMP runtime librariy)
could you please point documents which explain work flow of GOMP?
The GOMP project page:
http://gcc.gnu.org/projects/gomp/
The only article
Sir,
I want to know about gnu compiler project's aim.
Can i work for Gnu C compiler only.
Yours Sincerely
Bajrang Kr
On Thu, Mar 19, 2009 at 4:45 PM, bajrang kumar bajrang@gmail.com wrote:
Sir,
I want to know about gnu compiler project's aim.
http://gcc.gnu.org/gccmission.html
Can i work for Gnu C compiler only.
Yes
-Satya
http://www.linkedin.com/in/satyaakam
On Thu, Mar 19, 2009 at 05:32, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
The only difference in the branches name is a single letter (the last s of
plugins).
Yeah, I had forgotten about that branch and only remembered when I
went to edit the svn web page.
Given that the
Hi,
I tried to generate a cross-compiler from trunk a few hours ago and I have
noticed that
libgcc2.c doesn't compile anymore because of the following function :
int
mprotect (char *addr, int len, int prot)
{
DWORD np, op;
if (prot == 7)
np = 0x40;
else if (prot == 5)
np = 0x20;
On Thu, Mar 19, 2009 at 7:49 AM, Vincent R. foru...@smartmobili.com wrote:
Hi,
I tried to generate a cross-compiler from trunk a few hours ago and I have
noticed that
libgcc2.c doesn't compile anymore because of the following function :
It is caused by:
Hello everyone,
In attach I included the patch Albert Cohen was referring to.
Middle-end selection is performed by marking the regions of the source
code, that should be compiled for an specific ISA, using pragmas such
as:
#pragma target target_name
Or even to reset the above by just
On Thu, Mar 19, 2009 at 4:45 PM, bajrang kumar bajrang@gmail.com wrote:
Sir,
I want to know about gnu compiler project's aim.
http://gcc.gnu.org/gccmission.html
Can i work for Gnu C compiler only.
On Thu, Mar 19, 2009 at 05:21:06AM -0700, satyaakam goswami wrote:
Yes
See
Given that the svn://gcc.gnu.org/svn/gcc/branches/plugin branch is not
really active, I suggest to
svn mv svn://gcc.gnu.org/svn/gcc/branches/plugin
svn://gcc.gnu.org/svn/gcc/branches/old-plugin
What do you think about that?
I have no opinion on this. Eric and Sean should be consulted on
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer seze...@gmail.com wrote:
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of DWORD is not.. In any case, it should be
fixed easily by changing DWORD into unsigned int which is what a
DWORD is
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. foru...@smartmobili.com wrote:
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer seze...@gmail.com wrote:
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of DWORD is not.. In any case, it should be
Ozkan Sezer wrote:
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. foru...@smartmobili.com wrote:
However you are wrong about DWORD definition it has always be defined
like this :
typedef unsigned long DWORD, *PDWORD, *LPDWORD;
at least windows.
A DWORD on windows is an unsigned 32 bit
2009/3/19 Ozkan Sezer seze...@gmail.com:
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. foru...@smartmobili.com wrote:
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer seze...@gmail.com wrote:
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of
I now went through all backends except sh and made the required changes.
So far all I tested is that gcc compiles with one target per port. :-)
Plus, i386-linux bootstraps and regtests okay.
Right now I aim at 100% identical assembly, maybe I'll have to relax
that. Besides obvious register
On Thu, Mar 19, 2009 at 8:25 PM, Kai Tietz ktiet...@googlemail.com wrote:
2009/3/19 Ozkan Sezer seze...@gmail.com:
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. foru...@smartmobili.com wrote:
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer seze...@gmail.com wrote:
I'm a bit amazed that the
Richard Guenther wrote:
On Thu, Mar 19, 2009 at 1:44 AM, Jerry DeLisle jvdeli...@verizon.net wrote:
Hi folks,
In light of all the delays, I would like to propose that we create a
development / test branch for gfortran.
We could then start committing all the pending patches and if mainline
Besides obvious register allocation differences
m32c is very sensitive to register allocation issues.
you basically duplicate the cmp patterns into cbranch and
m32c already has a cbranch, though. It gets split after reload.
Also, m32c needs a separate compare RTL insn in the end
because
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
I agree about the bisecting-in-case-of-bugs issue.
However, what I see happening in practice is that all GCC developers
keep on doing their development work on branches - only the gfortran
developers are left out, because they do
On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
I agree about the bisecting-in-case-of-bugs issue.
However, what I see happening in practice is that all GCC developers
keep on doing their
* Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
Richard Guenther wrote:
Note that merging the branch will be painful (as in, please dissect
the branch into the individual patches again to make bisecting the
trunk SVN possible).
I agree about the bisecting-in-case-of-bugs issue.
For some reason sourceware seems to think this message was sent as
HTML instead of plaint text. Retry...
-- Forwarded message --
From: stevenb dot gcc at gmail dot com
Date: Thu, Mar 19, 2009 at 8:15 PM
Subject: Re: Re: Proposed gfortran development branch
To: (hidden)
On Mar
I'm pleased to report that GCC was once again accepted as a supported
project for Google's Summer of Code program. Summer of Code is a
program sponsored by Google in which students are paid to contribute to
open source projects. This will be GCC's fourth year of participation.
For more
Regarding ARC and MMIX we might expect some action from Joern and H-P
respectively, but nobody is probably going to do the work for the others
AFAIK ARC has no plans to do work on the old ARCtangent-A4 port that
is currently in gcc trunk. The ARCompact code is not suitable to be
integrated
Hi Ian,
Student applications will be accepted from March 23 to April 3. Each
student will work with a mentor from the project. As we've done in past
years, we need to have a set of mentors who are prepared to work with
students. I would like to encourage any interested experienced GCC
On Thu, 2009-03-19 at 20:14 +0100, Ralf Wildenhues wrote:
* Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
Richard Guenther wrote:
Note that merging the branch will be painful (as in, please dissect
the branch into the individual patches again to make bisecting the
trunk SVN
I tried building GCC with Graphite enabled and all the libraries it
requires in a Canadian cross configuration (build = i686-pc-linux-gnu,
host = i686-mingw32, target = arm-none-eabi). This failed with:
configure:11279: checking for the possibility to control the FPU
configure:11282: error: in
Snapshot gcc-4.3-20090319 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090319/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
2009/3/16 Jack Howarth howa...@bromo.med.uc.edu:
What about allowing for more backports from the graphite
branch if this drags out for an extended period of time? In
particular, I am thinking of those changes in graphite branch
that might reduce those cases where -fgraphite-identity
On Sun, Mar 15, 2009 at 9:39 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
I can't find any test results in gcc-testresults reported with
-mtune=itanium1 [1].
...especially if theye do not even contribute test results or
feedback when things are broken (as in this case). Deprecating
Itanium
Hello, my name is Eduardo Cruz. I am an studen.t of Computer Science
at the State University of Maringa, in Brazil.
One of our teachers gave us a work in wich we are supposed to modify
the c language to support some parallel programming stuff.
I want to modify the gcc c frontend to support these
NightStrike wrote:
On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
I agree about the bisecting-in-case-of-bugs issue.
However, what I see happening in practice is that all GCC developers
keep on
Hello to All,
I'm new in gcc list. And as all new members I have a problem.
I will copy an email whose I've sent to Joe Buck. If someone can
answer it for me, I really appreciate that.
Hi Joe Buck,
My name is Guilherme and I am a Brazilian undergraduate student in
Computer Science.
First of
On Thu, 2009-03-19 at 23:29 -0300, Eduardo Cruz wrote:
I thought gcc used bison as a syntax analyser, but when I saw the gcc
c-parser source code I realized that it didn't use bison.
I read in the gcc mailist that gcc now has a recursive descent parser.
That's right.
Do you have any
Ah, good, a duplicate question that I just answered. :-)
See http://gcc.gnu.org/ml/gcc/2009-03/msg00554.html
Ben
The fortran development branch has been created. The purpose is to
allow continuation of development of new Fortran 95 and Fortran 2003
features. A primary objective will be testing these features before
committing over to mainline, when appropriate.
A complete list of objectives can be
Ben Elliston wrote:
Ah, good, a duplicate question that I just answered. :-)
See http://gcc.gnu.org/ml/gcc/2009-03/msg00554.html
Ben
I bet Guilherme and Eduardo are in the same class at college!
http://www.din.uem.br/~hppca/membros.html
Ah! We can expect emails from Diego, Egidio,
On Mon, Mar 16, 2009 at 6:10 AM, Paolo Bonzini bonz...@gnu.org wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Given the SC request we need to stay in Stage 4 rather than trying to work
around it.
What if GCC went back to stage 3
--- Comment #7 from spop at gcc dot gnu dot org 2009-03-19 06:49 ---
Subject: Bug 39500
Author: spop
Date: Thu Mar 19 06:49:14 2009
New Revision: 144952
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144952
Log:
2009-03-19 Li Feng nemoking...@gmail.com
PR
--- Comment #8 from spop at gcc dot gnu dot org 2009-03-19 06:51 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from ayers at gcc dot gnu dot org 2009-03-19 07:07 ---
For the record: the official RFA was posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00666.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
--- Comment #5 from andreasmeier80 at gmx dot de 2009-03-19 07:47 ---
With revision 144946 everything is okay.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39498
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-19 07:58 ---
Created an attachment (id=17491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17491action=view)
gcc44-pr39496.patch
optimize, not !optimize.
Here is what I'm going to bootstrap/regtest.
--
jakub at gcc dot
--- Comment #9 from n dot pinhao at netvisao dot pt 2009-03-19 08:24
---
Created an attachment (id=17492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17492action=view)
Streamlined module files reproducing the error (2)
A file was missing on this test.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-19 10:11 ---
Closed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-19 10:25 ---
Subject: Bug 39496
Author: jakub
Date: Thu Mar 19 10:25:43 2009
New Revision: 144955
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144955
Log:
PR target/39496
* config/i386/i386.c
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-19 12:02 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #7 from gpderetta at gmail dot com 2009-03-19 12:14 ---
Hi, I'm the author of Boost.Coroutine (not yet part of boost, but one day...).
I have the exact same problem: gcc caches the address of TLS variables across
function calls which breaks when coroutines move from one
--- Comment #5 from sam at gcc dot gnu dot org 2009-03-19 10:15 ---
Matthias,
I think Laurent was asking for an executable test case, which fails before your
test and succeeds after, so that it can enter the regression suite.
--
sam at gcc dot gnu dot org changed:
What
--- Comment #3 from gerald at gcc dot gnu dot org 2009-03-19 10:40 ---
Subject: Bug 39063
Author: gerald
Date: Thu Mar 19 10:40:32 2009
New Revision: 144957
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144957
Log:
PR target/39063
* libgcc2.c (mprotect): Do not
The following fragment when compiled -O -ffinite-math-only on arm-linux-gnueabi
should print 0.00 but with gcc-4.1.2, 4.2.4, 4.3.3 it prints 9.00
#include stdio.h
#define test_min(x,y) ((x) (y) ? (y) : (x))
int
main (void)
{
static float data [1];
float min =
By compiling the attached files I get a warning like this:
./some_package-some_seperate_package.adb: In function
'SOME_PACKAGE.SOME_SEPERATE_PACKAGE.GET_STATE':
./some_package-some_seperate_package.adb:22: warning:
'state_infos.current_state' is used uninitialized in this function
but I think
--- Comment #1 from alex at segv dot de 2009-03-19 13:46 ---
Created an attachment (id=17493)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17493action=view)
spec file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
--- Comment #2 from alex at segv dot de 2009-03-19 13:46 ---
Created an attachment (id=17494)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17494action=view)
Body to spec
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
--- Comment #3 from alex at segv dot de 2009-03-19 13:47 ---
Created an attachment (id=17495)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17495action=view)
seperate body with code triggering the warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-19 14:52 ---
The fix may have broken cross compiling:
http://gcc.gnu.org/ml/gcc/2009-03/msg00525.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
When trying to generate a cross-compiler targeting arm-wince-pe I have noticed
that libgcc2.c was not compiling anymore because of the following function :
int
mprotect (char *addr, int len, int prot)
{
DWORD np, op;
if (prot == 7)
np = 0x40;
else if (prot == 5)
np = 0x20;
else
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-19 15:34 ---
Subject: Bug 39495
Author: jakub
Date: Thu Mar 19 15:34:00 2009
New Revision: 144965
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144965
Log:
PR c/39495
* c-omp.c (c_finish_omp_for): Allow
The attached test program -- which I extracted and simplified from the
'176.gcc'
SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The code is
correct at -O1 and -O0.
The bad code I am reporting here is produced by a MIPS gcc-4.3.3
cross-compiler.
However, I see the same problem
--- Comment #1 from jk500500 at yahoo dot com 2009-03-19 15:40 ---
Created an attachment (id=17498)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17498action=view)
Testcase (self-contained C file)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
--- Comment #2 from jk500500 at yahoo dot com 2009-03-19 15:44 ---
Created an attachment (id=17499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17499action=view)
gcc -v output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
--- Comment #1 from forumer at smartmobili dot com 2009-03-19 15:45 ---
Hum maybe there is a problem in my defines because libgcc2 is using some
windows functions and in particular mprotect so maybe I should try to find why
DWORD is not defined in my case.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-19 15:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from ramana dot r at gmail dot com 2009-03-19 15:53 ---
Adding self to CC list -
mainline is also broken. The only difference in mainline is that we generate a
movle instead of movgt.
It should indeed be a moveq instead of a movle.
cheers
Ramana
--
ramana dot r at
Sent from my iPhone
On Mar 19, 2009, at 8:38 AM, jk500500 at yahoo dot com gcc-bugzi...@gcc.gnu.org
wrote:
The attached test program -- which I extracted and simplified from the
'176.gcc'
SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3. The
code is
correct at -O1 and
--- Comment #4 from pinskia at gmail dot com 2009-03-19 16:01 ---
Subject: Re: New: Incorrect code at -O2 and -O3
Sent from my iPhone
On Mar 19, 2009, at 8:38 AM, jk500500 at yahoo dot com
gcc-bugzi...@gcc.gnu.org
wrote:
The attached test program -- which I extracted and
--- Comment #3 from jk500500 at yahoo dot com 2009-03-19 16:01 ---
Sorry, forgot to mention that the gcc command line is just:
mipsisa32-unknown-elf-gcc -O2 -S gcc0.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
--- Comment #2 from ramana dot r at gmail dot com 2009-03-19 16:05 ---
Or get rid of the cmp. The Runtime ABI suggests that the Z,N,C flags are set
for the result of the comparison. If that is true then the second cmp is
unnecessary.
Table 5 section 4.1.2 of the ARM Runtime ABI
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-19 16:07 ---
Yeah. In GCC this has been fixed by:
http://gcc.gnu.org/ml/gcc-patches/1999-01/msg00206.html
but SPEC2k contains older copy of GCC source code.
You need to either patch it, or use -fno-strict-aliasing to compile the
--- Comment #6 from jk500500 at yahoo dot com 2009-03-19 16:11 ---
Thanks for the info. I had assumed the SPEC code would not have issues like
this; guess not :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39504
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-19 16:19 ---
Btw, this was recently changed by
PR target/39063
* libgcc2.c (mprotect): Do not use signed arguments for
VirtualProtect, use DWORD arguments. Also fix the 'may
be used
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||arm-wince-pe
Keywords||build
--- Comment #3 from martinwguy at yahoo dot it 2009-03-19 16:29 ---
ramana:
I think you'll find the flags are only set for the 3-way comparisons.
__aeabi_cmple just returns 0 or 1
Use for C = in the table means the C language, not the carry flag.
If you can find where the error is in
A few compilers support a 'no arg check' compiler directive which tells the
compiler to ignore type/kind/rank checking on specified arguments. This is
useful when routines have 'generic' arguments which are simply passed on to
other routines. Two compilers which support this feature are ifort,
--- Comment #1 from etienne_lorrain at yahoo dot fr 2009-03-19 16:33
---
Also, you cannot put function in another section and then
use -ffunction-sections, i.e.:
etie...@gujin:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free
--- Comment #4 from ramana dot r at gmail dot com 2009-03-19 16:49 ---
(In reply to comment #3)
ramana:
I think you'll find the flags are only set for the 3-way comparisons.
__aeabi_cmple just returns 0 or 1
Use for C = in the table means the C language, not the carry flag.
If you
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-19 16:53
---
Also affects all other EABI target builds.
THe bug is in movsfcc (and movdfcc) which have not been corrected to account
for the libcall comparisons returning a bool value in the EABI.
I'm currently testing a fix
int i;
int foo (int *p, int b)
{
if (b)
p = i;
i = 1;
*p = 0;
return i;
}
at -O2 -fargument-noalias-global shows
# p_1 = PHI p_3(D)(2), i(3)
# i_7 = VDEF i_6(D)
i = 1;
# PARM_NOALIAS.10_9 = VDEF PARM_NOALIAS.10_8(D)
*p_1 = 0;
# VUSE i_7
D.1596_5 = i;
even though *p_1
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-19 16:58 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-19 17:00 ---
int i;
int __attribute__((noinline))
foo (int *p, int b)
{
if (b)
p = i;
i = 1;
*p = 0;
return i;
}
extern void abort (void);
int main()
{
if (foo((void *)0, 1) != 0)
abort ();
return 0;
}
--
--- Comment #12 from janis at gcc dot gnu dot org 2009-03-19 17:00 ---
I tested this patch, which I assume is what was described in comment #11:
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-19 17:02
---
Correction: it doesn't affect movdfcc since that only matches on hard-float
targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-19 17:02 ---
int foo (int *p, int b)
{
if (b)
p = i;
I think this is invalid for -fargument-noalias-*. I don't think you can assign
to another pointer to p with this option turned on with defined results because
it
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-19 17:03 ---
-fargument-noalias- is not flow sensitive at all and not supposed to be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39506
--- Comment #5 from dberlin at gcc dot gnu dot org 2009-03-19 17:10 ---
I agree with pinskia, and think this should be closed as invalid.
fargument-noalias-* is an assertion by you, the user, that these things will
never alias.
You are telling the compiler it is allowed to assume it is
--- Comment #6 from dnovillo at gcc dot gnu dot org 2009-03-19 17:12
---
(In reply to comment #5)
I agree with pinskia, and think this should be closed as invalid.
Likewise. At most we could emit a warning when we see p = i.
Diego.
--
--- Comment #5 from sezeroz at gmail dot com 2009-03-19 17:49 ---
The prototype for VirtualProtect() is known but the definition of DWORD is
not??
Hrmph. In any case, it should be fixed easily by changing DWORD into unsigned
int
which is what a DWORD is always defined as.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-19 18:08 ---
Really I think this is a bad idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
Hi,
vorbis is creating wrong output on armel when using -ffast-math and -O1 or
higher. It's the option -ffinith-math-only that cause the problems.
I tried and can reproduce this problem with gcc versions 4.1.3, 4.2.4 and
4.3.3.
I've tried this test on various arches without problem, including
--- Comment #1 from kurt at roeckx dot be 2009-03-19 18:17 ---
Created an attachment (id=17500)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17500action=view)
testcase showing the problem
/*
** This file is in the Public Domain.
**
** This program demonstrates a bug in
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-19 18:17 ---
*** This bug has been marked as a duplicate of 39501 ***
*** This bug has been marked as a duplicate of 39501 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-03-19 18:17 ---
*** Bug 39507 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 2009-03-19 18:47 ---
Confirmed, I saw this too while doing GCC work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from leo at marco dot de 2009-03-19 19:08 ---
Subject: Re: gcc generates incorrect trampoline code in
thumb mode
sam at gcc dot gnu dot org wrote:
--- Comment #5 from sam at gcc dot gnu dot org 2009-03-19 10:15 ---
Matthias,
I think Laurent was asking for
--- Comment #9 from jimb at red-bean dot com 2009-03-19 19:51 ---
Fixed for me in r144969. Thank you all!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39496
--- Comment #1 from amylaar at gcc dot gnu dot org 2009-03-19 19:55 ---
Due to having numerous subtargets and the close interaction between
branch shortening, alignment calculation, conditional execution and
instruction scheduling, and idiosyncrasies of the zero-overhead loop
1 - 100 of 121 matches
Mail list logo
