--- Comment #12 from ohl at physik dot uni-wuerzburg dot de 2010-07-06
07:38 ---
(In reply to comment #10)
> It is not particularly efficient to use a huge static variable. [...]
> initialization at run time is the better choice for large arrays. The best
> solution for PARAMETER depe
if I use thread binding in the following way:
export OMP_NUM_THREADS=8
export GOMP_CPU_AFFINITY="0 1 2 3 4 5 6 7"
for code that has three parallel regions:
!$omp parallel default(private) shared(bindings,n_thread)
!$omp end parallel
!$omp parallel default(private) shared(bindings,n_thread) num_t
--- Comment #1 from jv244 at cam dot ac dot uk 2010-07-06 08:03 ---
Created an attachment (id=21099)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21099&action=view)
testcase part 1
C code to report thread binding
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
--- Comment #2 from jv244 at cam dot ac dot uk 2010-07-06 08:05 ---
Created an attachment (id=21100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21100&action=view)
fortran testcase
build & run testcase as :
gfortran -fopenmp test.f90 get_affinity.c
export OMP_NUM_THREADS=8
expo
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-06 08:21 ---
That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs
upon thread creation, and the first two threads are never recreated in this
case.
Currently there is no tracking on how many threads bind to w
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-07-06 08:23
---
Even better, it actually works! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 08:44 ---
(In reply to comment #2)
> Actually it seems to be fallout of my local DECL_BY_REFERENCE change (so it
> does not reproduce on clean mainline).
> Apprently the result_slot_addr is something that is not allowed in mem
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-06 09:25 ---
Shorter testcase:
extern void abort (void);
static char
foo (char si1, char si2)
{
return si1 * si2;
}
int a = 0x105F61CA;
int
main (void)
{
int b = 0x0332F5C8;
if (foo (b, a) > 0)
abort ();
return 0;
}
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-06 09:33 ---
Not sure whether the testcase is valid or not. The multiplication using char
variables on both sides (and likewise for result) is: -54 * -56 (= 3024),
but (char) 3024 is -48. For int that would be clear undefined beh
--- Comment #13 from burnus at gcc dot gnu dot org 2010-07-06 09:46 ---
(In reply to comment #11)
> Regardless, we should catch this and issue the error message about
> -fmax-array-constructor. I don't see why we would want to do anything else.
I concur.
Juergen, does your program wor
--- Comment #4 from jv244 at cam dot ac dot uk 2010-07-06 10:01 ---
(In reply to comment #3)
> That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs
> upon thread creation, and the first two threads are never recreated in this
> case.
> Currently there is no trackin
--- Comment #24 from sfilippone at uniroma2 dot it 2010-07-06 10:14 ---
(In reply to comment #23)
> (In reply to comment #22)
> >
> generic_23.f03 obviously works becase the binding name DOIT and the procedure
> name are one and the same
>
Hi all
Another variation to the test case
--- Comment #25 from sfilippone at uniroma2 dot it 2010-07-06 10:15 ---
Created an attachment (id=21101)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21101&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
The recently added gcc/testsuite/gcc.c-torture/compile/pr44707.c fails on
sparc64 with -m32 -O1/-O2/-O3/-Os:
gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand
requires impossible reload
gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand
requires impossi
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-06 10:22 ---
Huh, I can't see how this should cause a debug compare failure.
Can you attach preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-06 10:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 10:30 ---
Confirmed. Reduced testcase:
typedef unsigned char UCHAR, *PUCHAR;
typedef void *HANDLE;
typedef struct _NCB {
UCHAR ncb_reserve[10];
} NCB, *PNCB;
struct NBCmdQueue {
PNCB head;
};
PNCB *NBCmdQueueFindNBC(
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-06 10:35 ---
The bug is that we have in .original
{
return si1 * si2;
}
while it should have been
{
return (char)((unsigned char) si1 * (unsigned char) si2);
}
which is premature optimization by convert_to_integer, short-
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 10:39 ---
What's the patch needed to trigger it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-06 10:42 ---
Guess sparc needs similar fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
--- Comment #5 from jv244 at cam dot ac dot uk 2010-07-06 11:32 ---
I also checked the pgi and cray compilers, they all lead to iforts thread
binding.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
I was trying to learn OOP in Ada and ran into this Assert Box:
$ gcc -c small.adb
+===GNAT BUG DETECTED==+
| 4.4.4 20100503 (Red Hat 4.4.4-2) (x86_64-redhat-linux-gnu) Assert_Failure
einfo.adb:1687|
| Error detected at small.adb:33:7
--- Comment #1 from bileam at gmail dot com 2010-07-06 11:41 ---
Created an attachment (id=21102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21102&action=view)
small.adb that triggers assert box.
Example program, trigger this bug with a simple
gcc -c small.adb
--
http://g
--- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> What's the patch needed to trigger it?
The DECL_BY_REFERENCE change. THe one I sent to list should be enough. So if
you could look into it, it
--- Comment #6 from rguenther at suse dot de 2010-07-06 11:45 ---
Subject: Re: Mozilla build ICE at Invalid first operand
of MEM_REF.
On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote:
>
>
> --- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 ---
> Subject: Re: Mozil
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-06 11:46 ---
I can't reproduce it with r161865. (on x86_64-linux with -m32)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
> Well, that sounds like caused by your needs_to_live_in_memory change.
>
> There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling.
Hmm, what kind of assymetry? Previously we special cased RESULT_DECL so it was
forced to memory even if it was pointer, no we don't. So things should
--- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> Well, that sounds like caused by your needs_to_live_in_memory change.
>
> There is asymmetry wrt caller / callee and DECL_BY_REFERENCE handling.
--- Comment #8 from rguenther at suse dot de 2010-07-06 12:16 ---
Subject: Re: Mozilla build ICE at Invalid first operand
of MEM_REF.
On Tue, 6 Jul 2010, hubicka at ucw dot cz wrote:
>
>
> --- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 ---
> Subject: Re: Mozil
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-06 12:23 ---
Reducing a testcase to look at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44826
MySQL relied on the behavior fixed in PR15638 to implement a poor man's ABI
check.
By keeping a copy of the preprocessed output, it was somewhat possible to
detect (via a diff) whether a change to some header might affect the ABI. MySQL
headers are a bit convoluted, being used by client programs a
I'm not really sure whether this is gcc bug or what but it used to work with
gcc 4.4.x and older.
Problem description:
I include which resides in /usr/include/sys/ucontext.h on my
system
this header contains (among others):
#ifdef __USE_GNU
enum
{
...
};
#endif
So to use th
--- Comment #1 from l dot jirkovsky at gmail dot com 2010-07-06 12:51
---
Created an attachment (id=21103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21103&action=view)
test file using definitions from the
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #2 from l dot jirkovsky at gmail dot com 2010-07-06 12:52
---
Created an attachment (id=21104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21104&action=view)
ucontext.h from my system
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #3 from l dot jirkovsky at gmail dot com 2010-07-06 12:53
---
Created an attachment (id=21105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21105&action=view)
preprocessed file missing __USE_GNU parts from ucontext.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from l dot jirkovsky at gmail dot com 2010-07-06 12:55
---
The strange thing is that when I copy the problematic part (even with
__USE_GNU) to a different file it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #7 from moonshine at kapsi dot fi 2010-07-06 12:57 ---
This issue is now fixed in trunk. I have no obligation to push it for 4.5
series as I am now able to build whole VICE successfully with 4.6 so I am
closing the ticket.
--
moonshine at kapsi dot fi changed:
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-06 12:58 ---
You're not supposed to define __USE_GNU yourself, see
The macro you should define is _GNU_SOURCE, which causes glibc to define
__USE_GNU
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #2 from froydnj at gcc dot gnu dot org 2010-07-06 13:02 ---
(In reply to comment #1)
> debian doesn't have all libraries needed as build dependencies as 64bit
> versions, so it's clear that the build fails. IMO not a GCC issue.
This same error occurs on systems where a nativ
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-06 13:02
---
Reduced testcase:
typedef unsigned short PRUint16;
typedef PRUint16 PRUnichar;
template struct nsCharTraits {
};
class nsAString_internal {
public:
typedef PRUnichar char_type;
};
class nsString : public ns
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-06 13:03 ---
Also, I don't think the change you're seeing can be from GCC, since
unconditionally does #undef __USE_GNU
Did you upgrade glibc at the same time as gcc?
In any case, you should use the documented interface, not __USE_
--- Comment #7 from l dot jirkovsky at gmail dot com 2010-07-06 13:11
---
Oh, sorry.
It was a part of source from rawstudio which used to work correctly but since
update to gcc 4.5.0 compilation fails. It took me some time to find where the
problem is and I found this.
--
http://g
--- Comment #8 from l dot jirkovsky at gmail dot com 2010-07-06 13:12
---
BTW: thank you for enlightening me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-07-06 13:18 ---
Created an attachment (id=21106)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21106&action=view)
i386.c preprocessed source
/user/inria/fsf/161802/bld-1/./prev-gcc/cc1plus -fpreprocessed i386.ii -quiet
-dumpb
--- Comment #9 from redi at gcc dot gnu dot org 2010-07-06 13:21 ---
then that's a bug in rawstudio, the relevant doc is
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44837
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-06 13:30
---
Index: tree-inline.c
===
--- tree-inline.c (revision 161865)
+++ tree-inline.c (working copy)
@@ -817,6 +817,12 @@ remap_gimple_op_r (tree
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 13:38 ---
Subject: Bug 44828
Author: rguenth
Date: Tue Jul 6 13:37:58 2010
New Revision: 161869
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161869
Log:
2010-07-06 Richard Guenther
PR middle-end/44828
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-06 13:40 ---
Fixed on trunk. The problem is latent everywhere but the optimization
doesn't happen for 4.2.4 or earlier.
Which makes it a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
On Linux/ia32, revision 161849 gave:
FAIL: gcc.dg/pr39794.c execution test
Revision 161840 is OK.
--
Summary: [4.6 regression] FAIL: gcc.dg/pr39794.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Linux/ia32, revision 161849 gave:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for excess errors)
FAIL: c-c++-common/uninit-17.c (test for excess error
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-06 14:09 ---
Reverting up to r161801 still gets me
> ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
g++: error: ii386.i: -fcompare-debug failure (length)
so it wasn't r161802.
-fcompare-debug do
--- Comment #6 from regehr at cs dot utah dot edu 2010-07-06 14:10 ---
(In reply to comment #2)
> Not sure whether the testcase is valid or not. The multiplication using char
> variables on both sides (and likewise for result) is: -54 * -56 (= 3024),
> but (char) 3024 is -48. For int t
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-06 14:13
---
Don't we have middle-end/44738 for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include
# include
using namespace std;
main() {
vector v;
vector::iterator i = v.begin();
--i;
cout << ( i - v.begin()
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Bootstrap fails after MEM- |[4.6 Regression] Bootstrap
|REF merge
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-06 14:28 ---
(In reply to comment #1)
> Don't we have middle-end/44738 for this?
>
They didn't fail for me on 32bit hosts before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
On Jul 6, 2010, at 7:21 AM, "andre dot bergner dot 0 at googlemail dot
com" wrote:
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include
# include
using namespace std;
m
--- Comment #1 from pinskia at gmail dot com 2010-07-06 14:40 ---
Subject: Re: New: bug in STL iterator class
On Jul 6, 2010, at 7:21 AM, "andre dot bergner dot 0 at googlemail dot
com" wrote:
> This is not a compiler bug, but a bug in the STL iterator class.
> The less-than-ope
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-07-06 14:42 ---
(In reply to comment #4)
> Reverting up to r161801 still gets me
>
> > ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i
> > -fcompare-debug
> g++: error: ii386.i: -fcompare-debug failure (length)
>
>
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-07-06 14:51 ---
(In reply to comment #4)
> Reverting up to r161801 still gets me
>
> > ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i
> > -fcompare-debug
I've tried this with --save-temps in r161600 and there's lo
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-06 14:57 ---
Created an attachment (id=21107)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21107&action=view)
Draft patch
--
burnus at gcc dot gnu dot org changed:
What|Removed |Adde
It was today that I stumbled over the seemingly simple situation of tweaking
some bits of an interface class.
Upon doing that, I got an undefined reference to a vtable.
I made clean and made my application. Nothing changed. Then I checked again the
interface and didn't find anything. Then I chec
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-07-06 15:03 ---
(In reply to comment #4)
> ./g++ -B. -c -O2 -march=pentiumpro -mtune=generic -m32 ii386.i -fcompare-debug
Works with g++ (GCC) 4.6.0 20100613 (experimental), fails with
g++ (GCC) 4.6.0 20100617 (experimental).
--
--- Comment #2 from paolo dot carlini at oracle dot com 2010-07-06 15:04
---
For sure.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
St
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-06 15:06
---
Bah, I would commonize these two bugs anyway, really that testcase is badly
broken essentially everywhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44839
GCC issues warnings like "division by zero" or "right shift count >= width of
type" even though the corresponding code will never be executed (under a
condition that is always false); it shouldn't do this, at least by default. For
instance:
int tst (void)
{
int x;
x = 0 ? 1 / 0 : 0;
return x
--- Comment #18 from burnus at gcc dot gnu dot org 2010-07-06 15:20 ---
Paul, thanks for the check in. Do you plan to backport it to 4.5, which sems to
use the same code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-06 15:21 ---
It is caused by revision 161844:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00198.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
d model: posix
gcc version 4.6.0 20100706 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-I.' '-I.' '-I./common' '-I./config'
'-DLOCALEDIR="/usr/share/locale"' '-DHAVE_CONFIG_H' '-I./../include/opcode'
'-I
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-06 15:26 ---
(In reply to comment #0)
>
> undefined reference to `vtable for IFoo'
> Suggestions:
>* Ensure that no (pure) member function of `IFoo' became unintentionally
> non-pure because of a missing or deleted `= 0'
W
--- Comment #19 from paul dot richard dot thomas at gmail dot com
2010-07-06 15:28 ---
Subject: Re: [OOP] Dynamic dispatch uses broken types
Dear Tobias,
> Paul, thanks for the check in. Do you plan to backport it to 4.5, which sems
> to
> use the same code?
Yes, I could do that on
--- Comment #4 from jojelino at gmail dot com 2010-07-06 15:38 ---
Created an attachment (id=21109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21109&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #5 from jojelino at gmail dot com 2010-07-06 15:39 ---
Created an attachment (id=21110)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21110&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #6 from jojelino at gmail dot com 2010-07-06 15:40 ---
Created an attachment (id=2)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=2&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #7 from jojelino at gmail dot com 2010-07-06 15:41 ---
Created an attachment (id=21112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21112&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #3 from pault at gcc dot gnu dot org 2010-07-06 15:42 ---
Created an attachment (id=21113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21113&action=view)
Fix for the PR
This version fixes the problem with channel.f90 and has cleaned-up/extra
comments
--
http://g
--- Comment #8 from jojelino at gmail dot com 2010-07-06 15:44 ---
and error messages combined
gcc -O2 -I. -I. -I./common -I./config -DLOCALEDIR="\"/usr/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/..
-I../bfd -I./../bfd -I./../include -I../l
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-06 15:47 ---
*** This bug has been marked as a duplicate of 42540 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-06 15:47 ---
*** Bug 44841 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from jojelino at gmail dot com 2010-07-06 15:50 ---
and gcc revision is 161868
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
--- Comment #2 from sandra at codesourcery dot com 2010-07-06 15:57 ---
s/caused by/exposed by/ ?
The patch to ivopts likely results in it selecting a different/smaller set of
loop induction variables, but I don't see how this change by itself could have
introduced a wrong-code error.
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-06 16:09 ---
Subject: Bug 44195
Author: bergner
Date: Tue Jul 6 16:09:13 2010
New Revision: 161872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161872
Log:
PR testsuite/44195
* gcc.dg/lto/20100518_0.c:
--- Comment #2 from mikpe at it dot uu dot se 2010-07-06 16:17 ---
This new FAIL of pr36745.C since r161655 is also seen on sparc64, ia64, arm,
and alpha.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
---
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, "vincent at vinc17 dot org" > wrote:
GCC issues warnings like "division by zero" or "right shift count >=
width of
type" even though the corresponding code will never be executed
(under a
condition
--- Comment #1 from pinskia at gmail dot com 2010-07-06 16:33 ---
Subject: Re: New: gcc should not issue warnings for code that will never be
executed
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, "vincent at vinc17 dot org"
wrote:
> G
--- Comment #3 from sje at cup dot hp dot com 2010-07-06 16:44 ---
The neccessary UNSPEC seems to be there if you trace the instructions back
far enough. I tried it on my test case and it worked. I am now testing the
patch on ToT to see if I can bootstrap. I also have to turn off part
Between 20100628 and 20100705, all 32-bit Fortran execution tests started to
FAIL
on Solaris 2. E.g. achar_1.exe:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff301d98 in *_gfortrani_free_format_hash_table (u=) at
/vol/gcc/src/hg/trunk/solaris/libgfortran
--- Comment #4 from bergner at gcc dot gnu dot org 2010-07-06 16:57 ---
Subject: Bug 44195
Author: bergner
Date: Tue Jul 6 16:57:21 2010
New Revision: 161874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161874
Log:
Backport from mainline
2010-07-06 Peter Berg
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-06 16:58 ---
Caused by, or exposed by ... in both cases your responsibility to investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-06 16:59 ---
Fixed in trunk and the 4.5 branch.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-06 17:24 ---
*** This bug has been marked as a duplicate of 4210 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #21 from manu at gcc dot gnu dot org 2010-07-06 17:24 ---
*** Bug 44842 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from manu at gcc dot gnu dot org 2010-07-06 17:28 ---
The way Clang gets this right is to perform some very-fast bitmap common
constant propagation in the FE. I personally think this would be helpful if
implemented correctly, even if it slows down the FE a little. But do
--- Comment #3 from manu at gcc dot gnu dot org 2010-07-06 17:34 ---
3 years in waiting... I am closing this, we have too many real bugs open to
worry about.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-06 17:35 ---
No feedback, unconfirmed, unreproducible, thus closing.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-06 17:39 ---
No duplicates in 3 years, no new feedback, closing this. Please reopen if
necessary.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
RDRAND instruction spec says:
Loads a hardware generated random value and store it in the destination
register. The size of the random value is determined by the destination
register size and operating mode. The Carry Flag indicates whether a random
value is available at the time the instruction i
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-06 17:41 ---
Too large testcase, no feedback in 3 years, no clear report. Closing...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-06 17:46 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00462.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from changpeng dot fang at amd dot com 2010-07-06 17:58
---
We also need to handle the post loop of unrolling. Suppose the unroll_factor
is 16, then the post-loop should have up to 15 iterations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
1 - 100 of 160 matches
Mail list logo
