--- Comment #4 from hp at gcc dot gnu dot org 2010-06-22 04:58 ---
FWIW, I didn't see this with r158717 (late April), so I think I'll just close
this PR. No, I don't think it's the same issue as PR44505; after all, these are
two wildly different architectures for which the test failed at
--- Comment #13 from paul dot richard dot thomas at gmail dot com
2010-06-22 04:36 ---
Subject: Re: gfortran generates wrong results due to wrong
ABI in function with array return
Dear Tobias,
Thanks for looking through the patch.
> Does use_assoc also include host-associat
--- Comment #6 from sandra at codesourcery dot com 2010-06-22 01:55 ---
Julian's patch overlapped some other NEON changes I was already preparing for
submission, so I did some refactoring before posting it for review. Here's the
main part of the fix:
http://gcc.gnu.org/ml/gcc-patches/2
--- Comment #3 from hp at gcc dot gnu dot org 2010-06-22 01:24 ---
(In reply to comment #2)
> Dupe of PR44505?
Unknown, please hold.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
---
atan2_1.f90 has failed on other platforms before too. I think we just need:
! { dg-options "-ffloat-store" }
or maybe this
! { dg-options "-O0 -ffloat-store" }
in the test file. Can you try that and see if
--- Comment #5 from ramana at gcc dot gnu dot org 2010-06-22 00:51 ---
Khem,
Can you check if this fixes your problem ? Feel free to submit this to
gcc-patches@ if you get around to testing this before me.
Ramana
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 628b
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- Comment #3 from bernds at gcc dot gnu dot org 2010-06-21 23:59 ---
At first glance, it looks like the tricks in the prefetch_cc simply aren't
valid. It seems to be trying to prevent certain types of addressing modes, but
reload is allowed to change them as it sees fit.
If I read th
--- Comment #5 from danglin at gcc dot gnu dot org 2010-06-21 23:54 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:54:25 2010
New Revision: 161124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161124
Log:
PR target/39690
config/pa/pa.c (override_opti
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-06-21 23:54
---
(In reply to comment #9)
> Hummm, I will work on your input, But now I have more questions:
>
> 1) Why do you call this case as explicit, and function call arguments implicit
> ? The way I see it, this is a specia
--- Comment #4 from danglin at gcc dot gnu dot org 2010-06-21 23:51 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:51:10 2010
New Revision: 161123
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161123
Log:
PR target/39690
config/pa/pa.c (override_opti
--- Comment #3 from danglin at gcc dot gnu dot org 2010-06-21 23:47 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:47:46 2010
New Revision: 161122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161122
Log:
PR target/39690
config/pa/pa.c (override_opti
--- Comment #3 from Daniel dot Davies at xerox dot com 2010-06-21 23:47
---
Yup, another mistake. The gold build fails. The version of g++ I'm using to
compile gold is too old (3.4.3 from the solaris distribution). I'll go try to
make a newer one.
g++ -DHAVE_CONFIG_H -I. -I/tool/gcc
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-21 23:43 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:43:42 2010
New Revision: 161121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161121
Log:
PR target/39690
config/pa/pa.c (override_opti
--- Comment #2 from Daniel dot Davies at xerox dot com 2010-06-21 23:42
---
Excellent! Here's where I must have gotten confused.
http://gcc.gnu.org/install/configure.html says
--enable-gold
Enable support for using gold as the linker. If gold support is enabled
together with --en
--- Comment #9 from edmar at freescale dot com 2010-06-21 23:36 ---
Hummm, I will work on your input, But now I have more questions:
1) Why do you call this case as explicit, and function call arguments implicit
? The way I see it, this is a special function call (implemented with a
jum
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-21 23:30 ---
>and LTO silently does nothing.
Huh? gold is not required for lto to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621
http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 says to use
/usr/bin/ksh as CONFIG_SHELL on solaris2.
When you do so, gcc-4.5.0/configure emits the following text:
> $TOOL/gcc/4.5.0/gcc-4.5.0/configure
> --prefix=$TOOL/gcc/4.5.0/i386-pc-solaris2.10 --with-gnu-as --with-gnu-ld
> --ena
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-21 23:20 ---
This change also probably introduced the following fails on
hppa-unknown-linux-gnu:
FAIL: gcc.c-torture/execute/frame-address.c execution, -O2
FAIL: gcc.c-torture/execute/frame-address.c execution, -O3
-fomit-fra
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-06-21 23:17 ---
This appears to be fixed on trunk, probably by:
2010-04-07 Simon Baldwin
* directives.c (do_diagnostic): Add warning reason argument,
call appropriate error reporting function for code.
[...]
--
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-21 23:03 ---
This was introduced by the following change:
Author: bernds
Date: Thu Jun 17 21:51:55 2010
New Revision: 160947
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160947
Log:
PR rtl-optimization/39871
--- Comment #8 from hjl at gcc dot gnu dot org 2010-06-21 21:59 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 21:58:38 2010
New Revision: 161119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161119
Log:
Properly handle psrldq when optimizing for Atom.
gcc/
2010-06-21 H
--- Comment #7 from hjl at gcc dot gnu dot org 2010-06-21 21:57 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 21:56:47 2010
New Revision: 161118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161118
Log:
Properly handle psrldq when optimizing for Atom.
gcc/
2010-06-21 H
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-06-21 21:29 ---
(In reply to comment #7)
> I mostly agree with you. But in this case, it is already a hard register (rtl
> generated in epilogue).
No the pattern accepts any registers which means register rename can rename the
reg
--- Comment #7 from edmar at freescale dot com 2010-06-21 21:18 ---
(In reply to comment #6)
> I think this is the wrong fix I think the problem is in the patterns not
> using a hard register or a constraint that says only those registers can be
> used.
>
> Confirmed.
>
I mostly
--- Comment #1 from soren dot soe at gonsoe dot com 2010-06-21 21:13
---
Created an attachment (id=20971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20971&action=view)
crash.ii
Attached crash.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44620
This simple source file causes gcc to crash when compiled with
-fvisibility-ms-compat:
void foo()
{
throw "Help!";
}
% gcc -v -save-temps -c -fvisibility-ms-compat crash.cxx
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../src/lnx32/configure
--prefix=/tools/batonroot/r
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-21 21:00
---
Revision 161061 has the same bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-21 20:57
---
Revision 161041 deosn't fix it on Linux/x86-64. I got
valgrind --tool=memcheck ./f951
/export/gnu/import/rrs/161041/src/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -mtun
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-21 20:54 ---
Confirmed on the trunk:
GNU C++ (GCC) version 4.6.0 20100621 (experimental) [trunk revision 161061]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100621 (experimental) [trunk revision
161061
host:~$ cat bogus.cpp
struct S { int x, y; };
int main(int argc, char *argv[])
{
struct S foo;
int S::*bar = &S::x;
foo.*bar = 5;
return foo.*bar;
}
host:~$ g++ -o bogus bogus.cpp -Wunused
bogus.cpp: In function 'int main(int, char**)':
bogus.cpp:5:12: warning: variable 'foo' set but not
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-06-21 20:34 ---
I think this is the wrong fix I think the problem is in the patterns not
using a hard register or a constraint that says only those registers can be
used.
Confirmed.
--
pinskia at gcc dot gnu dot org chang
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-21 20:28 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:28:24 2010
New Revision: 161114
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161114
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-21 20:28 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:28:03 2010
New Revision: 161113
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161113
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #4 from hjl at gcc dot gnu dot org 2010-06-21 20:26 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:26:11 2010
New Revision: 161112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161112
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #5 from edmar at freescale dot com 2010-06-21 20:24 ---
(In reply to comment #0)
Sorry for the spelling, please read "unknown" through out the report.
Thanks
Edmar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #2 from edmar at freescale dot com 2010-06-21 20:15 ---
Created an attachment (id=20968)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20968&action=view)
patch for 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #4 from edmar at freescale dot com 2010-06-21 20:17 ---
Created an attachment (id=20970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20970&action=view)
ChangeLog for proposed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #3 from edmar at freescale dot com 2010-06-21 20:17 ---
Created an attachment (id=20969)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20969&action=view)
ChangeLog for propsed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #1 from edmar at freescale dot com 2010-06-21 20:14 ---
Created an attachment (id=20967)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20967&action=view)
patch for 4.5 and 4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
On 32 bit powerpc targets, the family of out-of-line restore functions
(_restgpr__x), expects r11 (or something else, depending on the
ABI used) to have the new value of the stack pointer.
Gcc emits rtl that sets r11, and a jump_insn that flags the use of r11.
When compiling the test case with "-
--- Comment #8 from scott at perturb dot org 2010-06-21 19:03 ---
Here is the full command the arduino ide generates when it compiles code. I
just took the last command for sketch_jun21a.cpp.o (my code) and added the -v
and -save-temps.
avr-gcc -c -g -Os -w -ffunction-sections -fdata-se
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-06-21 18:40 ---
>*.i*
It should have produced a file that ended in .ii .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
--- Comment #6 from scott at perturb dot org 2010-06-21 18:39 ---
For the record, the code I'm attempting to compile is extremely simple. Might
explain why it compiles so cleanly:
---
void setup() {
Serial.begi
--- Comment #5 from scott at perturb dot org 2010-06-21 18:38 ---
* the complete command line that triggers the bug;
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
-I/home/bakers/arduino-0018/hardware/arduino/
--- Comment #2 from ubizjak at gmail dot com 2010-06-21 18:30 ---
Dupe of PR44505?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24344
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-21 18:30 ---
Here is a fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 161045)
+++ gcc/fortran/resolve.c (working copy)
@@ -1113
--- Comment #4 from scott at perturb dot org 2010-06-21 18:13 ---
(In reply to comment #3)
> Can you also try on a FSF released GCC rather than one that has been modified
> by the Fedora project?
That might be harder... I do see from the two forum posts that the bug persists
in GCC from
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-21 18:10 ---
Can you also try on a FSF released GCC rather than one that has been modified
by the Fedora project?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uros at gcc dot gnu dot org 2010-06-21 18:08 ---
Subject: Bug 44505
Author: uros
Date: Mon Jun 21 18:07:59 2010
New Revision: 161105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161105
Log:
PR testsuite/44505
* gcc.c-torture/execute/frame-ad
--- Comment #2 from scott at perturb dot org 2010-06-21 18:07 ---
* the exact version of GCC;
avr-gcc-c++-4.5.0-1.fc13.x86_64
avr-gcc-4.5.0-1.fc13.x86_64
* the system type;
Compiled on 2.6.33.5-112.fc13.x86_64 but the target was an atmega1280
* the options given when GCC
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 18:00 ---
Confirmed. Changing the CLASS statement into TYPE gives the correct error:
type(Connection) :: self
1
Error: the type of 'self' at (1) has not been declared within the interface
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-21 17:57
---
Did you read this, before opening the PR?
http://gcc.gnu.org/bugs/
Please provide all the required information, otherwise nobody will be able to
look at the issue.
--
paolo dot carlini at oracle dot com
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-21 17:48
---
I'm working on these, maybe will be ready in time for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-21 17:47
---
Reopening
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
St
There appears to be some sort of regression with avr-gcc 4.5.0. When compiling
a sketch for the atmega1280 everything works except for serial output. The fix
is to revert to 4.3.x
The issue is documented here:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1276727004/15
and
http://www.arduino.c
--- Comment #4 from raj dot khem at gmail dot com 2010-06-21 17:45 ---
(In reply to comment #3)
> Dupe of PR43961?
>
yes seems so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-21 17:43 ---
What's the reason why gfc_trans_zero_assign insists that len is INTEGER_CST?
At least if it is contiguous (and not assumed size), why can't memset be used
even for non-constant sizes?
--
http://gcc.gnu.org/bugzil
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-21 17:23 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02058.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #17 from jakub at gcc dot gnu dot org 2010-06-21 17:20 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #16 from jakub at gcc dot gnu dot org 2010-06-21 17:11 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 17:10:02 2010
New Revision: 161102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161102
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepa
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-21 17:07 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 17:06:48 2010
New Revision: 161100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161100
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepa
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-21 17:00 ---
(In reply to comment #9)
> (In reply to comment #7)
> > I cannot reproduce the factor of 10 results, however.
> Here this still is the case (so might depend on the precise architecture):
OK, I was using -fwhole-fil
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 16:51 ---
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > The following program compiles with g++ -O3 without errors or warnings
> >
> > Not with warnings enabled it doesn't!
> >
>
> Sorr
--- Comment #3 from mark dot haines at openmarket dot com 2010-06-21 16:47
---
(In reply to comment #1)
> (In reply to comment #0)
> > The following program compiles with g++ -O3 without errors or warnings
>
> Not with warnings enabled it doesn't!
>
Sorry,
g++ -O3 -Wall -Wextra swit
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-21 16:45 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The following program compiles with g++ -O3 without errors or warnings
>
> Not with warnings enabled it doesn't!
>
???
--
manu at gcc dot gnu dot org change
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-21 16:45 ---
(In reply to comment #0)
> FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
> FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)
I got
/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/xgcc
-B/
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 16:44 ---
Cf. also PR 44616 for the ICE reported at the mailing list.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html
For the program, gfortran ICEs with:
f951: internal compiler error: in find_typebound_proc_uop, at
fortran/class.c:660
The failing assert is:
gcc_assert (derived->f2k_derived);
Note: The original test case (see li
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-21 16:42 ---
(In reply to comment #0)
> FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t
> ]*%rsp
This is due to -mtune=atom generates:
leaq-88(%rsp), %rsp
instead of
subq$88,
On Linux/x86-64, I got
FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp
FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors)
with -mtune=atom.
--
Summary: -mtune=atom failed on sse2-ve
Based on a report by bd satish at
http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html
The following program is invalid as IMPORT is missing, but gfortran still
compiles it:
Expected: An error such as:
Error: line 12: SELF is of undefined derived type CONNECTION
or
error #6457: This derived ty
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-21 16:34 ---
Subject: Bug 44575
Author: jakub
Date: Mon Jun 21 16:33:49 2010
New Revision: 161097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161097
Log:
PR target/44575
* config/i386/i386.c (ix86_gimpli
--- Comment #13 from gnu at bluedreamer dot com 2010-06-21 16:31 ---
(In reply to comment #12)
> Is there a reason you changed the component back to c++?
> This is not a problem in the C++ compiler front-end.
>
I didn't mean to change anything. All I did was reply (maybe browser cached
--- Comment #12 from redi at gcc dot gnu dot org 2010-06-21 16:28 ---
Is there a reason you changed the component back to c++?
This is not a problem in the C++ compiler front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #14 from jakub at gcc dot gnu dot org 2010-06-21 16:27 ---
Subject: Bug 44426
Author: jakub
Date: Mon Jun 21 16:26:25 2010
New Revision: 161092
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161092
Log:
PR bootstrap/44426
* sel-sched-dump.h (sel_prepa
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-21 16:22 ---
(In reply to comment #0)
> The following program compiles with g++ -O3 without errors or warnings
Not with warnings enabled it doesn't!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
--- Comment #11 from gnu at bluedreamer dot com 2010-06-21 16:20 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Are these still relevant for c++0x? More so section 5 which says if they are
> > macros in C they must be macros in C++
>
> see 26.8 [c.math] paragraph 11
Thank
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-21 16:12 ---
(In reply to comment #9)
> Are these still relevant for c++0x? More so section 5 which says if they are
> macros in C they must be macros in C++
see 26.8 [c.math] paragraph 11
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #9 from gnu at bluedreamer dot com 2010-06-21 16:07 ---
> I agree the macro and template can't co-exist, but the template could be
> available as both std::signbit and ::signbit, and I think that's required by
> appendix D.
Are these still relevant for c++0x? More so section
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-21 15:56 ---
(In reply to comment #6)
> To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
> providing it in the global namespace, per se.
[depr.c.headers]/3
"The header assuredly provides the same declaration
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-21 16:02
---
To be clear: I'm against fiddling with *.h headers, basing on DR456. If you
want to do that, for each C library we support, good luck, but I'm not going to
help, sorry.
And note that appendix D talks about *th
--- Comment #47 from Kyle dot D dot Moffett at boeing dot com 2010-06-21
15:55 ---
(In reply to comment #41)
> Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view) [edit]
> e500.h and caller-save.c patch
>
> The ICE in #38 is due to a
--- Comment #9 from jv244 at cam dot ac dot uk 2010-06-21 15:49 ---
(In reply to comment #7)
> I cannot reproduce the factor of 10 results, however.
Here this still is the case (so might depend on the precise architecture):
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-l
The following program compiles with g++ -O3 without errors or warnings but sets
crash at the first printf. It seems to zero the stack pointer before calling
printf.
- Begin switch-crash.ii
# 1 "switch-crash.cpp"
# 1 ""
# 1 ""
# 1 "switch-crash.cpp"
extern "C" int printf (__const char *__restri
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-21 15:41
---
To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at
providing it in the global namespace, per se.
About signbit, if it's a macro in C it has to be undefined in order to
implement the facil
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-21 15:22 ---
(In reply to comment #7)
> I get for the example the following values, note especially the newly added
> CONTIGUOUS result:
For the test case, see attachment 20966 at PR 44612; that PR I have filled
because GCC does
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 15:17 ---
Created an attachment (id=20966)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20966&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612
Follow up to PR 41137.
Using the Intel compiler, the following program takes 0s for the loops (real
time: 0.005s); however, with
gfortran -fdump-tree-original -fwhole-program -flto -ffast-math -march=native
-O3 cont.f90
GCC needs 1.142s.
Expected:
* GCC also optimizes the loops away if the varia
--- Comment #7 from burnus at gcc dot gnu dot org 2010-06-21 15:02 ---
(In reply to comment #1)
> Just for reference, the difference in time between the two variants is truly
> impressive. About a factor of 11 with gcc 4.4 and 8 with gcc 4.5.
I get for the example the following values,
--- Comment #11 from ubizjak at gmail dot com 2010-06-21 14:53 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from uros at gcc dot gnu dot org 2010-06-21 14:52 ---
Subject: Bug 44546
Author: uros
Date: Mon Jun 21 14:52:07 2010
New Revision: 161085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161085
Log:
PR target/44546
* config/i386/predicates.md (ix86_
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-21 14:52 ---
But should std::signbit be available as ::signbit when is included, at
least for c++0x mode?
[depr.c.headers]/2 says
"Every C header, each of which has a name of the form name.h, behaves as if
each name placed in the
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-21 14:44 ---
FIXED on the trunk. Related items: is_contiguous() intrinsic and DO CONCURRENT
construct.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-21 14:44
---
I don't think signbit is special: including *any* header first undefs the
names, thus if they are defined as macros in C, you don't see them anymore in
the global namespace, only in std::. If, on the other han
--- Comment #6 from chris at bubblescope dot net 2010-06-21 14:35 ---
Of course, there is a big difference between an ICE and an infinite loop. Also,
bug which causes ICEs on one computer and not another need treating with great
care, as that suggests unpredictable memory corruption may
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-21 14:32 ---
Test starts to pass between revision 161046 and revision
161055 on Linux/ia64. Does anyone know which checkin fixes
this? This that a real fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
--- Comment #3 from gnu at bluedreamer dot com 2010-06-21 14:32 ---
Created an attachment (id=20965)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965&action=view)
--save-temps output .s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #2 from gnu at bluedreamer dot com 2010-06-21 14:31 ---
Created an attachment (id=20964)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964&action=view)
--save-temps output .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
--- Comment #1 from gnu at bluedreamer dot com 2010-06-21 14:31 ---
Created an attachment (id=20963)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963&action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
1 - 100 of 156 matches
Mail list logo
