#include
int n = 4, m = 2;
int main () {
for (;;) {
int i;
#pragma omp parallel for num_threads(m)
for(i = 0; i < 1; i++) {}
#pragma omp parallel for num_threads(n)
for(i = 0; i < 1; i++) {}
}
return 0;
}
When run on fr
--- Comment #4 from otte at gnome dot org 2009-05-17 09:05 ---
I cannot reproduce this anymore with gcc 4.3.3 from Ubuntu 9.04, so I consider
this fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-17 10:57
---
Character lengths are integers of kind value 4. This is not modified by
-fdefault-integer-8. Thus, when converting the index, which has kind value 8,
to the type of a character length, you get the warning with -Wc
An idea of semi-automatic optimization crossed my mind, which I could have
taken advantage on more than one project.
Imaging the code:
static int f1( int a, int b )
{
[... lots of computation using 'a', sometimes involving 'b' ...]
}
int main()
{
for (i=0; ihttp://gcc.gnu.org/bu
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-17 12:47
---
Subject: Bug 36260
Author: fxcoudert
Date: Sun May 17 12:47:00 2009
New Revision: 147633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147633
Log:
PR fortran/36260
* intrinsic.c (add_fun
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-05-17 12:49
---
Now audited and fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-05-17 12:58
---
Concur. Rather than use -fdefault-integer-8, consider using selected_int_kind
and explicitly declaring size of integers.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-05-17 13:40
---
This was an Apple bug; furthermore, it seems to have been fixed somewhere
between 10.5.2 and 10.5.7.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other |c
Ever Con
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-05-17 14:05
---
(In reply to comment #4)
> I am testing this patch at the moment.
> Could you please test it in your environment and tell me if it helps at all ?
Yes, that patch works for the code I was working on.
--
http:
The following program compiles without errors, but gives a segfault at runtime:
PROGRAM test_prog
PROCEDURE(triple), POINTER :: f
! This works
print *,triple(2.,4.)
! This creates a Segmentation Fault
f => triple
print *,f(2.,4.)
CONTAINS
FUNCTION triple(a,b) RESULT(tre)
REA
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-17 14:13 ---
-fdump-parse-tree yields:
triple (struct array1_real(kind=4) & __result, real(kind=4) & a, real(kind=4) &
b)
{
...
}
real(kind=4) (*) (real(kind=4) &, real(kind=4) &) f;
f = (real(kind=4) (*) (real(kind=4) &, re
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-17 14:24 ---
-fipa-cp has been there since 4.1.0.
It is now enabled in 4.4.0 and above by default at -O2 and above (including
-Os).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-17 15:28
---
Any news on this? I'd like to port the throw_allocator changes to 4_4-branch
too, because the allocator is badly broken otherwise.
--
paolo dot carlini at oracle dot com changed:
What|Remove
Hello all, this is a follow-up of #34870 . I tried to compile this one, and GCC
accepts, while it should reject it (it's not valid as #34870 might suggest):
struct A { template friend void f(A) { } };
int main() { f<1>(A()); }
The friend template function declared within class A is not visible a
--- Comment #10 from schaub-johannes at web dot de 2009-05-17 16:38 ---
A added another bug-report very similar to this that handles the case where the
friend definition is about a template:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40177 . GCC accepts in that case,
while it should rej
--- Comment #5 from manu at gcc dot gnu dot org 2009-05-17 16:39 ---
FIXED per previous comment.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
S
EABI ARM/Linux supports atomic builtins in gcc, but they are implemented as
calls to libgcc helper procedures with names like __sync_fetch_and_add_4() etc
rather than being expanded inline.
libstdc++v3/acinclude.m4 tests for atomic builtins by compiling source files
with calls to __sync_fetch_and_
--- Comment #5 from manu at gcc dot gnu dot org 2009-05-17 17:11 ---
This patch seems to fix the problem and still warn for the interesting cases.
Could you all test it in your targets? I can only test
x86-64-unknown-linux-gnu.
Index: gcc/c-common.c
=
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-17 17:12
---
This is essentially the same as PR40133, which is blocked by PR40134.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40178
I implemented another 'strlen' function with the same name, I didn't include
the 'stdio.h' file, but when I used -O1 flag, the function has been replaced by
"repnz scasb" without warning.
Test case is following:
$ cat test.c
int strlen(char* p)
{
return 0;
}
main()
{
return strl
--- Comment #2 from mikpe at it dot uu dot se 2009-05-17 18:01 ---
(In reply to comment #1)
> This is essentially the same as PR40133, which is blocked by PR40134.
Agreed. The underlying issue appears to be the static libgcc only symbols. One
wonders why they did things that way.
--
--- Comment #3 from jason at gcc dot gnu dot org 2009-05-17 18:01 ---
Subject: Bug 40139
Author: jason
Date: Sun May 17 18:01:33 2009
New Revision: 147638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147638
Log:
PR c++/40139
* pt.c (tsubst_qualified_id): Retain
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-17 18:05 ---
(In reply to comment #5)
> This patch seems to fix the problem and still warn for the interesting cases.
> Could you all test it in your targets? I can only test
> x86-64-unknown-linux-gnu.
>
The testcase in commen
--- Comment #7 from hjl at gcc dot gnu dot org 2009-05-17 18:37 ---
Subject: Bug 40172
Author: hjl
Date: Sun May 17 18:36:44 2009
New Revision: 147639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147639
Log:
gcc/
2009-05-17 Manuel López-Ibáñez
PR c/40172
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-17 18:42 ---
Because it was accident ...
*** This bug has been marked as a duplicate of 40133 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-17 18:42 ---
*** Bug 40178 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-05-17 18:54
---
Fixed on trunk and 4.4 branch, closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-17 19:10 ---
This is expected because strlen is a reserved name in the standard (even
without including string.h) except when the compiler moon is set to
freestanding mode (-ffreestanding) or you turn off the builtin.
--
pins
--- Comment #8 from hjl dot tools at gmail dot com 2009-05-17 19:25 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-17 19:47 ---
byte >>= bit;
is according to C
byte = (int)byte >> bit;
you see the (partly redundant) zero-extensions. It has nothing to do with
partial register stalls.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-05-17 20:02 ---
Still does not fix the PPC-darwin bootstrap:
cc1: warnings being treated as errors
/Users/regress/tbox/svn-gcc/gcc/toplev.c: In function 'process_options':
/Users/regress/tbox/svn-gcc/gcc/toplev.c:2043: error: logica
--- Comment #10 from hjl dot tools at gmail dot com 2009-05-17 20:14
---
(In reply to comment #9)
> Still does not fix the PPC-darwin bootstrap:
> cc1: warnings being treated as errors
> /Users/regress/tbox/svn-gcc/gcc/toplev.c: In function 'process_options':
> /Users/regress/tbox/svn-g
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-05-17 20:17
---
Maybe the warning is correct but with macros like this, it is hard to avoid the
warning really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-17 20:20
---
I don't think this warning is particularly useful if it breaks even GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
--- Comment #4 from jason at gcc dot gnu dot org 2009-05-17 20:34 ---
Subject: Bug 40139
Author: jason
Date: Sun May 17 20:34:30 2009
New Revision: 147643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147643
Log:
PR c++/40139
* semantics.c (finish_id_expression)
--- Comment #13 from manu at gcc dot gnu dot org 2009-05-17 20:47 ---
If GCC does not want to be warned about
if (!x && x)
then the warning is not useful for GCC. Then take it out of -Wextra. But it is
definitely useful for others, and it found a bug in IRA.
--
http://gcc.gnu.org/
--- Comment #2 from baichangjun at gmail dot com 2009-05-17 23:08 ---
It is not expected. I have done some tests with gcc i386, x86_64, amd64 and
powerpc version. only i386 compiler replaces strlen by builtin function. the
other compilers gave a warning msg: "warning: conflicting types f
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-17
23:20 ---
Subject: Re: FAIL: ext/throw_allocator/deallocate_global.cc execution test
> Any news on this? I'd like to port the throw_allocator changes to 4_4-branch
> too, because the allocator is badly broken otherw
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-18 00:36 ---
Hmm, The warning is a bit weird because the return type of strlen is size_t
which is unsigned int on i686-linux-gnu and unsigned long on x86_64-linux-gnu
but we ignore the signness for some reason.
--
http://gcc
--- Comment #4 from rmansfield at qnx dot com 2009-05-18 03:55 ---
I can no longer reproduce the problem with gcc 4.4.0 or trunk (4.5.0 20090518
revision 147649). I was able to reproduce it with gcc 4.3.3 release.
I'm indifferent to whether the PR is resolved as fixed in 4.4/4.5 or reso
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-18 04:46 ---
(In reply to comment #0)
> In the following program, env%n should be equal to zero when entering the
> routine "titi" but one gets the output :
>
> 10 0
>5 10
>
> instead of
>
> 10 0
>5 0
I get the corr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-18 06:41 ---
I can reproduce the problem with GCC 4.2.1,
but it works with 4.3.3 [gcc-4_3-branch revision 144878]. Thus it seems to be
fixed in newer 4.3 versions than your 4.3.0 2008-03-05. And it works in 4.4.x
and 4.5. Please u
--- Comment #1 from aoliva at gcc dot gnu dot org 2009-05-18 06:54 ---
I (and the automated regression testers) can't seem to duplicate this. May I
have a bit more detail as to the circumstances in which the problem occurs,
please?
--
aoliva at gcc dot gnu dot org changed:
44 matches
Mail list logo
