Hello
On 17.11.08, you wrote:
> Hi,
>
> I'd like to pointer that the new __optimize__ attribute doesn't work
> correctly:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
>
> Will it be fixed in 4.4?
68k amigaos target on 4.4 give no error, when type this to try to switch
optimizer of
On Mon, Nov 17, 2008 at 06:46:38PM -0800, Andrew Pinski wrote:
> I noticed that for a simple testcase:
> int t;
> void abort (void);
>
> int f(int t, const int *a)
> {
> const int b[] = { 1, 2, 3};
> if (!t)
> return f(1, b);
> return b == a;
> }
Note that in the above function, called
Hi folks.
Though I would have preferred to work in mainline with the appropriate
maintainers (Joseph, et al) approving my patches, there seems to be no
way I can limit the invasiveness of my diagnostics work... even though
it's technically a regression and/or bug fix. It can't make it to 4.4,
wit
I am moving to a new job and will no longer be able to serve as the Xtensa port
maintainer for GCC. I would like to nominate Sterling Augustine to take my
place. Sterling has done a lot of work on the GNU assembler and recently worked
on GCC with me to use DWARF unwinding for Xtensa. I think
On Tue, 18 Nov 2008, Aldy Hernandez wrote:
> Hi folks.
>
> Though I would have preferred to work in mainline with the appropriate
> maintainers (Joseph, et al) approving my patches, there seems to be no
> way I can limit the invasiveness of my diagnostics work... even though
> it's technically a
Hey there,
Not too long ago miguel rosa sent you an invite to join the Scour search
community and your invite is still open!
The Scour search engine is shaped by a community of users just like you,
and your contributions are what make it a success!
Why use Scour?
1. Get Yahoo, Google and MSN res
I think, Intel's FMA instructions are different from the FMA
instructions covered in -mfma (inside -msse5). I believe Intel's FMA
should be part of a separate switch.
> Also I am not sure if "-mavx -msse5" or "-mavx -msse4a" make any
senses. I
> think
> -mavx should turn off -msse5/-msse4a and vic
gcc.c-torture/execute/pr36321.c fails on m32c because the simulator
doesn't set argv[0] *and* the simulator has NULL pointer detection:
void foo(char *str)
{
int len2 = strlen (str);
. . .
int main(int argc, char **argv)
{
foo (argv[0
> What are the expectations here? Do we expect simulators to set up
> argv[0]? (the m32c BSP acts like you're on real hardware) Do we expect
> simulators to blithely ignore NULL pointer references?
I think a more relevant question is whether it's ok to pass 0, {NULL} for
argc, argv. If yes then
On Tue, Nov 18, 2008 at 2:13 PM, rajagopal, dwarak
<[EMAIL PROTECTED]> wrote:
> I think, Intel's FMA instructions are different from the FMA
> instructions covered in -mfma (inside -msse5). I believe Intel's FMA
That is true.
> should be part of a separate switch.
I added -mfma in AVX patch. Cur
> In addition, we need to consider the interests of translators, who need
> some time before a release to translate new and changed messages without
Ah. Agreed.
Another thing. Patches to the branch should be tested against the GCC
regression suite *and* the GDB testsuite. Assume any upcoming
> I think a more relevant question is whether it's ok to pass 0, {NULL} for
> argc, argv.
You can do that on desktop linux, you know:
execl(some_prog_name, NULL);
argv[0] is NOT guaranteed to be non-NULL:
ISO/IEC 9899:1999(E) 5.1.2.2.1
2 If they are declared, the parameters to the main
On Tuesday 18 November 2008, DJ Delorie wrote:
> > I think a more relevant question is whether it's ok to pass 0, {NULL} for
> > argc, argv.
>
> You can do that on desktop linux, you know:
>
> execl(some_prog_name, NULL);
>
> argv[0] is NOT guaranteed to be non-NULL:
>
> ISO/IEC 9899:1999(E)
Hello, thank you everybody for your help.
I used malloc to create my arrays instead of creating the in the stack. My
program is working now but it is very slow.
I use two-dimensional arrays. The way I access element (i,j) is:
array_name[i*row_length+j]
The server that I use has 16GB ram. The ul
Anna Sidera wrote:
Hello, thank you everybody for your help.
I used malloc to create my arrays instead of creating the in the stack. My
program is working now but it is very slow.
I use two-dimensional arrays. The way I access element (i,j) is:
array_name[i*row_length+j]
The server that I use
On Tue, Nov 18, 2008 at 6:08 PM, Anna Sidera <[EMAIL PROTECTED]> wrote:
> Hello, thank you everybody for your help.
>
> I used malloc to create my arrays instead of creating the in the stack. My
> program is working now but it is very slow.
>
> I use two-dimensional arrays. The way I access elemen
16 matches
Mail list logo
