--- Comment #18 from tkoenig at gcc dot gnu dot org 2010-06-04 06:51
---
Fixed (finally).
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from tkoenig at gcc dot gnu dot org 2010-06-04 06:50
---
Subject: Bug 34670
Author: tkoenig
Date: Fri Jun 4 06:50:11 2010
New Revision: 160253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160253
Log:
2010-06-04 Thomas Koenig
PR libfortran/34670
--- Comment #6 from amodra at gmail dot com 2010-06-04 04:59 ---
fixed
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from amodra at gcc dot gnu dot org 2010-06-04 04:58 ---
Subject: Bug 44075
Author: amodra
Date: Fri Jun 4 04:58:05 2010
New Revision: 160248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160248
Log:
PR target/44075
* gcc/config/rs6000/rs6000.c (s
--- Comment #4 from amodra at gcc dot gnu dot org 2010-06-04 04:57 ---
Subject: Bug 44075
Author: amodra
Date: Fri Jun 4 04:57:21 2010
New Revision: 160247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160247
Log:
PR target/44075
* gcc/config/rs6000/rs6000.c (s
--- Comment #3 from amodra at gcc dot gnu dot org 2010-06-04 04:57 ---
Subject: Bug 44075
Author: amodra
Date: Fri Jun 4 04:56:54 2010
New Revision: 160246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160246
Log:
PR target/44075
* gcc/config/rs6000/rs6000.c (s
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-04 04:40 ---
Fixed as of revision 160215.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-04 04:38 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #6 from amodra at gmail dot com 2010-06-04 03:03 ---
Fixed mainline.
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
02:17 ---
Created an attachment (id=20832)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20832&action=view)
Even tinier tc-lossings-floats.objdump
--
Kyle dot D dot Moffett at boeing dot com changed:
--- Comment #15 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
02:17 ---
Created an attachment (id=20831)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20831&action=view)
Even tinier tc-lossings-floats.c
Spent a bit more time on the testcase and made it even smaller. T
--- Comment #14 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
01:37 ---
Created an attachment (id=20830)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20830&action=view)
Updated tc-lossings-floats.objdump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #13 from Kyle dot D dot Moffett at boeing dot com 2010-06-04
01:37 ---
Created an attachment (id=20829)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20829&action=view)
Updated tc-lossings-floats.c
I sat down with GCC and vim for a couple hours narrowing down Sebastia
--- Comment #9 from exploringbinary at gmail dot com 2010-06-04 01:31
---
I discovered two other examples of incorrect rounding in gcc:
1) 0.500166533453693773481063544750213623046875
2) 1.50011102230246251565404236316680908203125
These are both halfway cases.
--- Comment #6 from maksim at kde dot org 2010-06-04 00:55 ---
I can provide an .i file, but it would be on x86 (with 4.4.3). Is it likely to
be of use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-06-04 00:46 ---
(In reply to comment #5)
> Ok, let me open another PR. Would you suggest somebody to add in CC?
Maybe we should have a meta-bug for all the issues with this warning flag.
So that'd be at least this one, PR 44361, an
--- Comment #73 from iains at gcc dot gnu dot org 2010-06-04 00:40 ---
(In reply to comment #72)
> Created an attachment (id=20822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822&action=view) [edit]
> config patch for test
>
> config/tls.m4 - modified as per Jakub's suggesti
This one causes tons of warnings in the libstdc++ testsuite (with -Wall in
CXXFLAGS) and seems also bogus to me.
struct ratio
{
static const int a = 3;
};
const int ratio::a;
int f()
{
ratio r;
return r.a;
}
--
Summary: Another bogus set-but-not-used warning
Produc
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-04 00:28
---
Ok, let me open another PR. Would you suggest somebody to add in CC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44362
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-04 00:25 ---
(In reply to comment #3)
> Is this also the same issue? Probably not, but it causes tons of warnings in
> the libstdc++ testsuite (with -Wall in CXXFLAGS) and seems bogus to me.
I don't see any connection (beyond th
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-04 00:17
---
Is this also the same issue? Probably not, but it causes tons of warnings in
the libstdc++ testsuite (with -Wall in CXXFLAGS) and seems bogus to me.
struct ratio
{
static const int a = 3;
};
const int ratio
--- Comment #4 from sandra at codesourcery dot com 2010-06-04 00:09 ---
I've been looking at this problem today. Here's the stupid part coming out of
ivopts:
:
# ivtmp.7_21 = PHI <0(2), ivtmp.7_20(4)>
# ivtmp.10_22 = PHI
count_25 = (int) ivtmp.10_22;
if (count_25 != 0)
got
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-03 23:51
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from paolo at gcc dot gnu dot org 2010-06-03 23:50 ---
Subject: Bug 44410
Author: paolo
Date: Thu Jun 3 23:50:29 2010
New Revision: 160239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160239
Log:
2010-06-03 Paolo Carlini
PR libstdc++/44410
*
--- Comment #38 from iains at gcc dot gnu dot org 2010-06-03 23:45 ---
(In reply to comment #37)
> (In reply to comment #35)
> > Note the failures occur only with -m64, not with -m32.
>
> This may due to a misconfiguration of libjava similar to pr43170. I am
> bootstrapping with the lat
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-03 23:31
---
Actually, the testcases must be fixed, qualifying size_t with std::. I'll do
that momentarily as obvious.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Ad
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-03 23:27 ---
see http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ for more
details of copy elision and why it is a good thing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44409
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-03 23:23 ---
Good luck with that.
Your copy constructor doesn't copy the state of the source object. Complaints
like this usually only come up in unrealistic examples created to test a
compiler's behaviour. There are many, many si
On Linux/ia32, revision 160231:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html
caused:
FAIL: g++.dg/eh/new1.C (test for excess errors)
FAIL: g++.dg/init/new5.C (test for excess errors)
FAIL: g++.old-deja/g++.jason/new.C (test for excess errors)
FAIL: g++.old-deja/g++.law/operators27.C (test
--- Comment #12 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
23:18 ---
(From update of attachment 20823)
Scratch my test cases... "register asm(...)" doesn't work the way I thought it
did... Sebastian's test case is the only one that I've found that works.
--
Kyle dot D
--- Comment #3 from gcc at razorcam dot com 2010-06-03 23:04 ---
Thanks for your answers. From the above answers I understand that g++ respects
the ISO c++ standard, and thus you can consider this is not a bug. But this is
clearly an explicit call of the copy constructor, not an implicit
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-03 22:42 ---
Yes, this is eligible for copy elision, see [class.copy]
when a temporary class object that has not been bound to a reference (12.2)
would be copied/moved
to a class object with the same cv-unqualified type, the copy/
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 22:37 ---
I think this one case is where the copy constructor can be skipped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44409
the following command always outputs 1 instead of the expected 0
g++ bug_report.cpp && ./a.out ;echo $?
g++ does not output anything during the compilation
the output of g++ -v -save-temps follows the source file bug_report.cpp
the preprocessed file bug_report.ii is at the end of this report
struc
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 22:13 ---
It does
$ gcc-4.3 -S t.c -Wall -Wconversion
t.c: In function main:
t.c:13: warning: conversion to unsigned int from int may change the sign of
the result
t.c:13: warning: conversion to int from unsigned int
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-03 22:12 ---
I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ c_lto_20100603-2_0.o -O0
-fwhopr -r -nostdlib -m32 -o gcc-dg-lto-20100603-2-01
--- Comment #16 from tkoenig at gcc dot gnu dot org 2010-06-03 21:45
---
Looking at what is actually in there...
> associated.c
This doesn't have any bounds issues.
> date_and_time.c
I'll replace an assert with a runtime_error.
> dtime.c
No changes needed.
> etime.c
No changes n
--- Comment #2 from okingsmith at nuvation dot com 2010-06-03 21:38 ---
I am confused why the compiler is not issuing a warning on the second division.
Ir is sign converting the numerator to match the denominator (which makes
sense at a certain level), and hence can produce unexpected r
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-03 21:22 ---
There is nothing unexpected here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 21:12 ---
Subject: Bug 44403
Author: rguenth
Date: Thu Jun 3 21:12:38 2010
New Revision: 160235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160235
Log:
2010-06-03 Richard Guenther
PR tree-optimization/
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-03 21:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #37 from dominiq at lps dot ens dot fr 2010-06-03 20:57 ---
(In reply to comment #35)
> Note the failures occur only with -m64, not with -m32.
This may due to a misconfiguration of libjava similar to pr43170. I am
bootstrapping with the latest patch and I'll redo the testing
--- Comment #11 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:26 ---
Created an attachment (id=20828)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20828&action=view)
Multipart trivial testcase objdump result (Built with -O3)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:26 ---
Created an attachment (id=20827)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20827&action=view)
Multipart trivial testcase objdump result (Built with -O0)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20826&action=view)
Multipart trivial testcase (For -O3) part 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20825&action=view)
Multipart trivial testcase (For -O3) part 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20824&action=view)
Multipart trivial testcase (For -O3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:21 ---
Created an attachment (id=20823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20823&action=view)
Combined trivial testcase (For -O0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #5 from gcc at breakpoint dot cc 2010-06-03 20:17 ---
>So clearly the caller's assembly is wrong; it should be saving all 64-bits of
>r9 (volatile gpr) first.
Yes, that it what I've been pointing out. There is an optimization in the stack
code which uses 32bit stores/loads i
On Linux/ia32, revision 160229 gave:
FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O0
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O2
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-3
I have seen the following code produce an unexpected result on two different
gcc compilers. I compile the following code
#include
int main()
{
int a, d1, r1, r2;
unsigned int d2;
a = -10;
d1 = 2;
d2 = 3;
r1 = a / d1;
r2 = a / d2;
--- Comment #4 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:09 ---
Ok, I have a trivial 19-line testcase that triggers the bug on my native Debian
GCC 4.4.4-2+powerpcspe1 (with PR44169 fix) with -O0 and -O3. The compiler was
built with: --with-cpu=8548 --enable-e500_doub
--- Comment #72 from iains at gcc dot gnu dot org 2010-06-03 20:06 ---
Created an attachment (id=20822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822&action=view)
config patch for test
config/tls.m4 - modified as per Jakub's suggestion
*/configure regenerated as necessary.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 19:39 ---
Created an attachment (id=20821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20821&action=view)
patch
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
19:26 ---
(In reply to comment #0)
> So after looking at the code I saw now the following:
> 1c24 <__floatdidf>:
> 1c6c: 11 23 1a 2c evmergehi r9,r3,r3
>
> This function is touching the complete 6
--- Comment #5 from torbenh at users dot sourceforge dot net 2010-06-03
19:15 ---
(In reply to comment #4)
> Unfortunately the preprocessed source from comment #1 seems to be
> damaged, I get loads of errors like "error: stray '\336' in program."
> Can you please re-upload it? Thanks.
--- Comment #2 from torbenh at users dot sourceforge dot net 2010-06-03
19:10 ---
Created an attachment (id=20820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20820&action=view)
preprocessed signals_test.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44406
--- Comment #1 from torbenh at users dot sourceforge dot net 2010-06-03
19:08 ---
Created an attachment (id=20819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20819&action=view)
code that crashes when compiled
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44406
attached code crashes, when compiled with -ftree-sra
works fine with 4.4.2
its probably an incarnation of PR44258
--
Summary: wrong code generation with -ftree-sra
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
P
--- Comment #71 from jakub at gcc dot gnu dot org 2010-06-03 19:02 ---
Yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-03 18:55 ---
The "naming the constructor" stuff is DR 147, but I agree that this testcase
should be accepted since lookup doesn't find the injected-class-name.
--
jason at gcc dot gnu dot org changed:
What|Remov
--- Comment #4 from ccoutant at gcc dot gnu dot org 2010-06-03 18:29
---
> Cary - why does lto-plugin get invoked when gold has errors?
Gold doesn't stop on these kinds of errors -- it proceeds to the end of the
link to try to diagnose as many errors as possible. I'm not sure why a
mul
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-03 18:25 ---
(In reply to comment #2)
> auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
> on April 12, 2005, so I'd think that PR 20972 is due to something
> else. They do both involve the same assembler mes
--- Comment #70 from dominiq at lps dot ens dot fr 2010-06-03 18:23 ---
(In reply to comment #68)
> That makes sense, so all we need to do in config/tls.m4 is probably:
> 1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
> nor a_in_other_thread should be stati
--- Comment #69 from howarth at nitro dot med dot uc dot edu 2010-06-03
18:20 ---
So the tls tests in the generated configure should be changed as follows?
--- gcc-4.5.0/libgomp/configure.orig2010-06-03 13:05:23.0 -0400
+++ gcc-4.5.0/libgomp/configure 2010-06-03 13:41:14.00
--- Comment #2 from kazu at gcc dot gnu dot org 2010-06-03 18:18 ---
Andrew,
auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
on April 12, 2005, so I'd think that PR 20972 is due to something
else. They do both involve the same assembler message though.
--
http
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 18:01 ---
*** This bug has been marked as a duplicate of 44362 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 18:01 ---
*** Bug 44405 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-03 17:59 ---
I'm currently testing if the patch for PR 44361 helps for this failure too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44405
I am trying to build mainline GCC (revision 160215) configured
with -enable-build-with-cxx .
I get the following error during bootstrap:
/user/inria/fsf/bldxx-20100603/./prev-gcc/g++
-B/user/inria/fsf/bldxx-20100603/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 17:27 ---
Looks related to PR 20972.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404
Consider:
char buf[128];
extern void bar (int a, const char *p);
extern char *strcpy (char *, const char *);
void
foo (int a)
{
if (a)
bar (0, buf);
strcpy (buf, "0123456789abcdefghijklmnopqrstuvwxyz");
bar (0, buf);
}
Compile this testcase with arm-none-linux-gnueabi-4.4.
strcpy abo
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-03 17:00
---
Jason certainly followed these developments, I remember, let's CC him.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #68 from jakub at gcc dot gnu dot org 2010-06-03 16:58 ---
That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
nor a_in_other_thread should be static
2) move a_in_main_thread = &a;
--- Comment #2 from schaub-johannes at web dot de 2010-06-03 16:45 ---
The Standard allows this at 9.2/13a ("In addition, if class T has a
user-declared constructor (12.1), every nonstatic data member of class T shall
have a name different from T."). In our case we don't have a user decl
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-03 16:40
---
Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-03 16:36 ---
Subject: Bug 44294
Author: hjl
Date: Thu Jun 3 16:36:22 2010
New Revision: 160229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160229
Log:
Check MAX_FIXED_MODE_SIZE on bit-field in C++.
gcc/ada/
2010-06-03
--- Comment #67 from iains at gcc dot gnu dot org 2010-06-03 16:12 ---
I am puzzled by this apparent fail when the tests that depend on the variables
being distinct are all passing.
So, I think I've got a hunch;
If the spawned thread finishes before pthread_create () returns, then the
to/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Modified:
trunk/gcc/testsuite/lib/lto.exp
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #36 from iains at gcc dot gnu dot org 2010-06-03 16:08 ---
(In reply to comment #35)
> Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
>
> ...
> set_ld_library_path_env_vars:
> ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.li
to/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/lto/20100603-1_0.C
trunk/gcc/testsuite/g+
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 16:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-03 15:49
---
Created an attachment (id=20818)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20818&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44403
For the following function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
}
the following is generated in the .optimized file:
xxx (short int * restrict a, short int * restrict b)
{
vector(2) short int * vect_p.27;
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 15:32 ---
There was a defect report in the C++ standard about X::X; I cannot remember
what happens with a member variable being named the same as the class name
though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44401
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:31 ---
Cary - why does lto-plugin get invoked when gold has errors?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:28 ---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:26 ---
Reconfirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|201
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:24 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from dominiq at lps dot ens dot fr 2010-06-03 15:21 ---
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke: /opt/gcc/build_w/x86_64-
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 15:14 ---
Ah, it does not work because we mangle foobar to foobar.1234, not because
we eliminate it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-03 15:13 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last recon
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:08 ---
Similar to PR41844.
*** This bug has been marked as a duplicate of 41844 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:08 ---
*** Bug 42675 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-03 15:07 ---
The assert has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This code is valid, but rejected by GCC:
struct A { void f(); };
typedef void F();
struct B { friend F A::f; };
// error: type 'A' is not derived from type 'B'
--
Summary: GCC does not accept friend function declarations using a
typedef for function type.
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-03 15:03 ---
This is fixed. I have a testcase + testsuite patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from iains at gcc dot gnu dot org 2010-06-03 15:03 ---
(In reply to comment #33)
> On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of
> r160219
> cause
>
> === libjava Summary for unix/-m64 ===
>
> # of expected passes2
This code is valid, but GCC rejects it:
struct X { int X; };
int X::*p = &X::X;
// error: taking address of constructor 'X::X'
GCC apparently seems to think that X::X looks up to the injected class name,
and thus (by 3.4.3.1/1a) would name the constructor. But the name of the
non-static data mem
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-03 14:55 ---
Fixed by revision 159343:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00395.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
1 - 100 of 144 matches
Mail list logo
