--- Comment #6 from bart dot vanassche at gmail dot com 2009-06-07 07:09
---
(In reply to comment #5)
> You have to read the code to understand how that happens.
> But basically GOMP_parallel_start does:
> gomp_team_start (fn, data, num_threads, gomp_new_team (num_threads));
>
> Wher
--- Comment #8 from eres at il dot ibm dot com 2009-06-07 07:12 ---
Created an attachment (id=17959)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17959&action=view)
patch to fix syntax errors in tests
This patch should fix the syntax errors.
I'll sumbit it also if the problem i
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Sample code:
#include
int main() {
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, "ashutosh dot sharma dot 0204 at gmail
dot com" wrote:
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free
--- Comment #1 from pinskia at gmail dot com 2009-06-07 07:23 ---
Subject: Re: New: Array + XOR swap fails
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, "ashutosh dot sharma dot 0204 at gmail
dot com" wrote:
> C
--- Comment #9 from dominiq at lps dot ens dot fr 2009-06-07 07:48 ---
The patch in comment #8 fixes the failures reported in comment #7. I now see
(powerpc-apple-darwin9 with -m64):
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
forced using versioning" 3
--- Comment #2 from irar at il dot ibm dot com 2009-06-07 07:59 ---
So, I guess this patch fixes it?
Thanks,
Ira
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 148035)
+++ tree-vect-patterns.c
--- Comment #2 from schwab at linux-m68k dot org 2009-06-07 09:04 ---
*** This bug has been marked as a duplicate of 11751 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--
--- Comment #85 from schwab at linux-m68k dot org 2009-06-07 09:04 ---
*** Bug 40366 has been marked as a duplicate of this bug. ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--
--- Comment #10 from eres at il dot ibm dot com 2009-06-07 10:51 ---
(In reply to comment #9)
> The patch in comment #8 fixes the failures reported in comment #7. I now see
> (powerpc-apple-darwin9 with -m64):
> FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
>
--- Comment #10 from paolo dot carlini at oracle dot com 2009-06-07 11:07
---
Benjamin, do you have a strong opinion about this issue? I don't, really, but
especially in the light of the C++0x drafts (thanks to Greg for pointing it
out), I would close for now the issue with a patch addi
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-07 11:53 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 11:53:21 2009
New Revision: 148243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243
Log:
2009-06-07 Daniel Franke
PR fortran/25104
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 11:53 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 11:53:21 2009
New Revision: 148243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243
Log:
2009-06-07 Daniel Franke
PR fortran/25104
--- Comment #7 from jakub at gcc dot gnu dot org 2009-06-07 13:07 ---
valgrind just isn't smart enough to understand it.
Obviously --enable-linux-futex build has a lot of synchronization primitives
that are beyond what valgrind is able to understand, but even with the posix
only primitiv
--- Comment #11 from hjl dot tools at gmail dot com 2009-06-07 13:26
---
It is caused by revision 147980:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #12 from hjl at gcc dot gnu dot org 2009-06-07 13:35 ---
Subject: Bug 32950
Author: hjl
Date: Sun Jun 7 13:35:05 2009
New Revision: 148244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148244
Log:
2009-06-07 H.J. Lu
PR middle-end/32950
* g++.dg/
--- Comment #13 from hjl at gcc dot gnu dot org 2009-06-07 13:38 ---
Subject: Bug 32950
Author: hjl
Date: Sun Jun 7 13:38:38 2009
New Revision: 148245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148245
Log:
2009-06-07 H.J. Lu
Backport from mainline:
2009-
--- Comment #14 from hjl at gcc dot gnu dot org 2009-06-07 13:40 ---
Subject: Bug 32950
Author: hjl
Date: Sun Jun 7 13:39:54 2009
New Revision: 148246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148246
Log:
2009-06-07 H.J. Lu
Backport from mainline:
2009-
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-07 13:46 ---
Subject: Bug 36874
Author: burnus
Date: Sun Jun 7 13:45:47 2009
New Revision: 148247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148247
Log:
2009-06-07 Daniel Franke
* check.c (dim_rank_check)
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-07 13:59 ---
Compile time check is now there (4.5 trunk). Missing is a run-time check.
Example:
real, dimension(1,0) :: a, b, c
integer :: sp(3), i
a = 4.0
sp = 1
i = 1
b = eoshift (a,sp(1:i)) ! Invalid
end
NAG f95
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:24 ---
Does this need a 4.4 backport? I'm inclined to think not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-07 14:27 ---
(In reply to comment #4)
> Yeah. Looking through our local changes, I think you just need this line in
> i386.h:
>
> #define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_MACHO ? 4 : (TARGET_SSE ?
> 3
> : 0)))
>
>
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-07 14:37 ---
> Does this need a 4.4 backport? I'm inclined to think not.
Good question. As it is no regression, backporting is not required; it is a
wrong-code bug, but strides are rather special. Thus for me either is OK -
back
--- Comment #8 from hjl at gcc dot gnu dot org 2009-06-07 14:37 ---
Subject: Bug 40328
Author: hjl
Date: Sun Jun 7 14:36:55 2009
New Revision: 148248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148248
Log:
2009-06-07 H.J. Lu
Backport from mainline:
2009-0
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:39 ---
I don't want to do any backport to 4.3 any more.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from tkoenig at gcc dot gnu dot org 2009-06-07 14:41 ---
If nobody minds, I'll do this (it's part of PR 34670
anyway).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-07 14:41
---
(In reply to comment #11)
> It is caused by revision 147980:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
>
Revision 147978 also does not work if you compile the testcase with
the -fno-tree-sra switch
The gfortran manual page is missing a description of "-Wextra".
The description of "-Wunused-parameter" mentions the use of "-Wall -Wextra",
but nowhere in the manual page is -Wextra described.
--
Summary: -Wextra description missing from gfortran manual page
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 15:52 ---
-Wextra is documented in the standard GCC manual.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-06-07 15:55
---
Wait, (In reply to comment #15)
> (In reply to comment #11)
> > It is caused by revision 147980:
> >
> > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
> >
>
> Revision 147978 also does not work if you comp
--- Comment #2 from weeks at iastate dot edu 2009-06-07 16:14 ---
The description in the gcc manual page states the behavior for C/C++; little of
it could apply to Fortran. It would be nice to know how how this option
affects Fortran code (e.g., does it turn on all the warnings not enab
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-07 16:20 ---
No, the gcc man page applies to all languages of the GNU Compiler collection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 16:35 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 16:35:06 2009
New Revision: 148249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249
Log:
2009-06-07 Daniel Franke
PR fortran/25104
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 16:35 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 16:35:06 2009
New Revision: 148249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249
Log:
2009-06-07 Daniel Franke
PR fortran/25104
A function ends with:
pointer->field = callSomething();
(where pointer is obtained via an argument (a pointer to struct) passed to the
function).
At -O1 and above, if -foptimize-sibling-calls is on, the call is converted to a
jump, losing the assignment.
--
Summary: -foptimize-sibl
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 16:40 ---
What target is this for?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
C
--- Comment #2 from john at iastate dot edu 2009-06-07 16:45 ---
I will attach the -v -save-temps output, but it is large, so...
The source:
static void ListInit (
Listthis,
int argc,
va_list ap
) {
ListPrivate private = PRIVATE(this);
--- Comment #3 from john at iastate dot edu 2009-06-07 16:46 ---
Using built-in specs.
Configured with:
/home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configu
re --enable-long-long --disable-multilib --enable-threads --disable-symvers
--bu
ild=i386-unknown-netbsdelf --host=i386-
--- Comment #4 from john at iastate dot edu 2009-06-07 16:49 ---
Created an attachment (id=17960)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17960&action=view)
List.i from -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-07 16:50 ---
3.3 has not been supported release of the FSF for a couple of years now.
Since this is a modified version of GCC, you should report it to the folks who
maintain it (in this case netbsd).
--
pinskia at gcc dot g
--- Comment #10 from aldot at gcc dot gnu dot org 2009-06-07 16:54 ---
4.3.3 does not simplify it, 4.4.0 onward do.
for reference
4.3.3:
Substituing values and folding statements
Constants propagated: 0
Copies propagated: 0
Predicates folded: 0
ior (bD.1193)
{
--- Comment #6 from john at iastate dot edu 2009-06-07 17:04 ---
OK, thanks. I will see about getting a newer gcc.
I borrowed a machine with gcc 4.1.2 and it seems to have been fixed by that
point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
--- Comment #7 from john at iastate dot edu 2009-06-07 17:10 ---
PS, if there was an obvious place to find which versions are supported that
would be most helpful -- I sire couldn't find it on the website...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
The following code was tried :
/* File1.c*/
#include
#define _q "
int main()
{
printf(_q ABC _q);
}
When given the -E option, I get
int main()
{
printf(" ABC ");
}
but when the same code was compiled ( gcc File1.c ), then the following errors
were received :
7 : missing terminating " characte
--- Comment #19 from burnus at gcc dot gnu dot org 2009-06-07 17:33 ---
Subject: Bug 29962
Author: burnus
Date: Sun Jun 7 17:33:34 2009
New Revision: 148250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250
Log:
2009-06-07 Daniel Franke
PR fortran/25104
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 17:33 ---
Subject: Bug 25104
Author: burnus
Date: Sun Jun 7 17:33:34 2009
New Revision: 148250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250
Log:
2009-06-07 Daniel Franke
PR fortran/25104
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-06-07 17:40
---
Subject: Bug 40334
Author: jvdelisle
Date: Sun Jun 7 17:40:24 2009
New Revision: 148251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148251
Log:
2009-06-07 Jerry DeLisle
PR libfortran/40334
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-06-07 18:57
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 18:57:43 2009
New Revision: 148252
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148252
Log:
2009-05-31 Jerry DeLisle
PR fortran/40008
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:01
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 19:00:47 2009
New Revision: 148253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148253
Log:
2009-06-07 Jerry DeLisle
PR libfortran/40008
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:08
---
Subject: Bug 40008
Author: jvdelisle
Date: Sun Jun 7 19:07:46 2009
New Revision: 148255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148255
Log:
2009-06-07 Jerry DeLisle
PR fortran/40008
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-07 19:20
---
Also works for me on newer versions. This is very likely PR 36817. Please try a
more recent compiler and reopen this bug if it persists.
--
fxcoudert at gcc dot gnu dot org changed:
What|Remove
The following invalid code snippet triggers an ICE since GCC 4.4.0:
=
struct A
{
static int i;
};
template struct B
{
int x[A::i];
};
=
bug.cc:8:13: internal compiler error: tree check: did not expect class 'type',
have 'type' (
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
struct A
{
typedef void (&F)();
template operator F();
};
void foo()
{
A()();
}
=
bug.cc: In function 'void foo()':
bug.cc:9:7: internal compiler
The following invalid code snippet triggers an ICE since GCC 4.4.0:
==
template struct A
{
int i;
friend void foo() { int x[i]; }
};
struct B
{
int j;
friend int bar() { return j; }
};
==
bug.cc: In function 'void fo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
The following invalid code snippet triggers an ICE:
==
struct A;
namespace { struct A; }
struct B {};
template void foo(T t)
{
t.~A();
}
void bar()
{
foo(B());
}
==
bug.cc: In function 'void foo(T)':
bug.cc:8:6: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
--- Comment #4 from weeks at iastate dot edu 2009-06-07 22:15 ---
I was somehow looking at an older version of the gcc manual page; the 4.4.0
version does describe -Wextra. Mea culpa.
--
weeks at iastate dot edu changed:
What|Removed |Added
--
--- Comment #24 from aldot at gcc dot gnu dot org 2009-06-07 22:51 ---
Nick,
As mentioned in #22 the following hunk that was in the patch was not applied:
diff --git a/gcc/config/arm/linux-elf.h b/gcc/config/arm/linux-elf.h
index 07455ee..d8e65d2 100644
--- a/gcc/config/arm/linux-elf.h
--- Comment #7 from kkojima at gcc dot gnu dot org 2009-06-07 22:58 ---
Created an attachment (id=17961)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17961&action=view)
test case for 4.3
A reduced test case for 4.3 -O2 -fpic on sh4-unknown-linux-gnu.
--
http://gcc.gnu.org/bu
The gcc 4.4.0 manual states:
When -fopenmp is specified, the compiler generates parallel code according
to
the OpenMP Application Program Interface v2.5
Per (http://gcc.gnu.org/gcc-4.4/changes.html), GCC 4.4.0 supports OpenMP 3.0.
--
Summary: OpenMP version needs updating in
Compile the following code with -mthumb -O2 -Os,
extern void foo(int*, const char*, int);
void test(const char name[], int style)
{
foo(0, name, style);
}
I got:
push{r4, lr}
mov r3, r0 // A
mov r2, r1 // B
mov r0, #0
--- Comment #1 from carrot at google dot com 2009-06-08 03:23 ---
Created an attachment (id=17962)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17962&action=view)
test case shows the redundant register move
This problem occurs quite frequently if both caller and callee have multi
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-08 03:27 ---
This might be caused by scheduling before the register allocator (or maybe the
lack of).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
The new option -municode incorrectly defines UNICODE. Instead, it should
define _UNICODE. Jon_Y provided the following suggestion for a fix:
Index: gcc/config/i386/mingw-w64.h
===
--- gcc/config/i386/mingw-w64.h (revision 148266)
++
66 matches
Mail list logo
