Command line:
gcc -fno-trapping-math testcase.c
-- testcase.c --
int foo(_Decimal64 x[2])
{
return !(x[0] < x[1]);
}
Tested revisions:
r157877 - crash
r153685 - crash
4.4 r157895 - OK
Compiler output:
$ /mnt/svn/gcc-trunk/binary-157877-lto/bin/gcc -fno-trapping
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-31 21:41
---
OK to commit, trunk is not quite Frozen yet, so please proceed. Also, please
backport to 4.4 in a bit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
--- Comment #7 from bernds at codesourcery dot com 2010-03-31 21:42 ---
A patch is at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01274.html
--
bernds at codesourcery dot com changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |target
Keywords||ice-on-valid-c
--- Comment #32 from mikpe at it dot uu dot se 2010-03-31 21:43 ---
(In reply to comment #31)
> There appears to be a mistaken presumption running through this thread that
> there is a 1<->1 mapping between unwind blocks and source language functions.
> This is not the case, and any cod
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-31 21:47 ---
This is by design and the patch even mentions that Visual Studio 2005 follows
the same rule.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from vz-gcc at zeitlins dot org 2010-03-31 22:04 ---
I'm sorry but is this really all you have to say about this? Granted, VS does
follow the same rule but the size of object files produced by it was twice
less than that of object files produced by gcc _before_ this change
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-31 22:11 ---
Also this change was done to so we would be compliant to the ARM EABI.
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01481.html
And if the linker is taking a lot of memory, then it is a bug in the linker.
The linke
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-31 22:12 ---
And really it make sense that the functions are exported are marked as
dllexport even if they are vague linkage.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from vz-gcc at zeitlins dot org 2010-03-31 22:25 ---
(In reply to comment #3)
> And if the linker is taking a lot of memory, then it is a bug in the linker.
> The linker should not take much more memory for functions which are linked
> once.
Let's admit this. How does it
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-31 22:32 ---
My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not
to export inline functions also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #7 from vz-gcc at zeitlins dot org 2010-03-31 22:36 ---
(In reply to comment #6)
> My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not
> to export inline functions also.
Andrew, could you please provide a reasonable alternative to what we do?
Also
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-31 22:49 ---
It's not very hard to add a define_peephole2 pattern for this case also,
although it's a bit of a hack.
I'm not even sure if it would handle the case cmp+mov and mov+cmp case -- does
peephole2 care about the order of
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-03-31
22:50 ---
(In reply to comment #4)
> Not exactly a primary or secondary target. CCing maintainer.
I have been trying to find a complete list of gcc primary and secondary targets
with no luck so far. But at least thi
--- Comment #5 from steven at gcc dot gnu dot org 2010-03-31 22:51 ---
...remove accidental CC-list additions...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-31 22:55 ---
Primary/secondary targets are listed on
http://gcc.gnu.org/gcc-4.5/criteria.html. That list should probably be
clarified for GCC 4.6 to explain what arm-eabi means, exactly. It makes little
sense to me, to make arm-ea
--
ccoutant at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot
|dot org
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-03-31
23:30 ---
Is it expected that the lines...
/* Add code:
static gcov* __gcov_indirect_call_counters; // pointer to actual counter
static void* __gcov_indirect_call_callee; // actual callee address
*/
are comm
Command line:
gcc -O3 -fkeep-inline-functions testcase.C
or
gcc -O2 -fipa-cp-clone -fkeep-inline-functions testcase.C
or
gcc -O1 -fipa-cp -fipa-cp-clone -fkeep-inline-functions testcase.C
- testcase.C -
#include
std::stringstream ss;
--
I am reducing the preprocessed t
--- Comment #10 from ccoutant at gcc dot gnu dot org 2010-03-31 23:40
---
Created an attachment (id=20267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20267&action=view)
Gold patch to fix common symbol handling
This gold patch ought to fix the problem. Please verify and I'll se
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-03-31
23:51 ---
Those add code comments are from the patch first proposed...
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
If internally all floats are treated as double, then if I throw exception in
the below code as double(which is 100.0) and catch as float why the program
terminates, rather the catch of float should also be elevated to double type in
the absence of explicit catch of double.
try{
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-01 00:54 ---
100.0 is of a type double in C++, not float. Try 100.0f.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43612
Thanks.
au
http://www.xprad.org/
Bugzilla from gcc-bugzi...@gcc.gnu.org wrote:
>
> The commit of...
>
> Author: rguenth
> Date: Tue Mar 30 13:10:16 2010
> New Revision: 157822
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157822
> Log:
> 2010-03-30 Seongbae Park
>
Sorry to duplicately reporting this bug, but i failed to get a feedback after i
announced it after another small bug unfortunately.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477
/libcpp/files.c: Line 609-614:
comparison is always false under win x64
and
/gcc/emit-rtl.c: Line 361:
/gcc/ggc-
--- Comment #5 from aflyhorse at foxmail dot com 2010-04-01 01:04 ---
Failed to build with sse3, i surrounded...
--
aflyhorse at foxmail dot com changed:
What|Removed |Added
--
--- Comment #2 from korikov at hotmail dot com 2010-04-01 01:09 ---
(In reply to comment #1)
> 100.0 is of a type double in C++, not float. Try 100.0f.
>
yes 100.0f works as well as (float)100.0 but the point is when the compiler
does automatic conversion from float to double, then wh
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-01 01:11 ---
I figure this is worth fixing in the ~22-hour window remaining before 2nd
April. The option although deprecated should not for preference be released in
a broken state, and since it worked in all previous versions (i.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-01 01:15 ---
>gcc/src/gcc/ira-conflicts.c: Line 125:
That is printing out a long correctly (has no pointers in it, though it does
have a sizeof).
>gcc/src/gcc/tree-dump.c: Line 168:
/gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-01 01:15 ---
Because that is not the C++ standard says it should do :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
me/regehr/z/compiler-install/gcc-r157896-install
--program-prefix=r157896- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100331 (experimental) (GCC)
--
Summary: ice in gimple_rhs_has_side_effects, at gimple.c:2248
Product: gcc
Versi
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-01 03:07 ---
# VUSE <.MEM_13>
D.1996_8 = MEM[symbol: g_2, index: D.2003_16];
We should not have any VOPs here as this statement is volatile.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-01 03:09 ---
But that is not a regression as 4.3.2 have:
# VUSE
D.1207_8 = MEM[symbol: g_2, index: D.1220_19];
4.1 is also broken:
# VUSE ;
D.1624_9 = MEM[symbol: g_2, base: D.1674_4];
--
http://gcc.gnu.org/bugzi
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-04-01
05:11 ---
Proposed patch posted to
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg5.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-04-01
05:13 ---
Created an attachment (id=20268)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20268&action=view)
proposed patch to fix visibility issues on darwin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from ccoutant at gcc dot gnu dot org 2010-04-01 06:32
---
Created an attachment (id=20269)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20269&action=view)
Updated gold patch to fix common symbol handling
Sorry, I forgot to include the updated testsuite/Makefile.*
--- Comment #1 from zsojka at seznam dot cz 2010-04-01 06:41 ---
Created an attachment (id=20270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20270&action=view)
auto-reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
101 - 137 of 137 matches
Mail list logo
