--- Comment #10 from burnus at gcc dot gnu dot org 2010-02-17 07:32 ---
(NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default but
rejects it with -stand f95 or -stand f03.)
I think one should really send a interpretation request.
A patch would be the following. Wh
--- Comment #2 from raj dot khem at gmail dot com 2010-02-17 06:18 ---
this warning also triggers with current head/4.5.0
--
raj dot khem at gmail dot com changed:
What|Removed |Added
I got
FAIL: gcc.target/i386/xop-vpermil2pd-1.c (test for excess errors)
FAIL: gcc.target/i386/xop-vpermil2pd-1.c (test for excess errors)
FAIL: gcc.target/i386/xop-vpermil2pd-256-1.c (test for excess errors)
FAIL: gcc.target/i386/xop-vpermil2pd-256-1.c (test for excess errors)
FAIL: gcc.target/i38
--- Comment #8 from hjl dot tools at gmail dot com 2010-02-17 04:51 ---
It failed on Linux/x86-64:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.dg/ext/attrib36.C:8:56:
warning: '__stdcall__' attribute ignored^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/g++.d
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-17 04:43 ---
Isn't the M1 a thumb2 only target or is it a combo thumb2/arm target? If it is
the later, are you sure that you don't want blx instead?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
The "bl " instruction from the assembly to a function written in 'C
language', generates an exception.
Unable to proceed..
tried all other options.
guess this is with the compiler,
--
Summary: ARM V6 (Cortex-M1) Unable to jump from assembly to C
code while debug
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-17 03:41 ---
It is caused by revision 153682:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg01338.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-02-17 02:06
---
After reading the thread on clf, its still not very clear. The wording is less
then perfect, but thinking out of the box I suppose it would be reasonable to
allow it in the namelist as long as the array gets allo
--- Comment #12 from bangerth at gmail dot com 2010-02-17 02:00 ---
(In reply to comment #11)
> Only if the transitive property doesn't hold for workarounds. I think it does
> ;)
But you keep dodging the question whether we have regressed on the
workaround.
Anyway, this is now PR 43101
The kludge used as a workaround for PR 26261 doesn't work any more:
---
template class X {};
template class Y {
static const unsigned int dim = 1;
X::dim> f();
};
template
X::dim> Y::f() { return X(); }
--
This compiled with gcc 4.3, but
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-17 01:51
---
> As for the workaround in #5: it would be a workaround for a workaround.
> That would be sorta silly.
Only if the transitive property doesn't hold for workarounds. I think it does
;)
--
http://gcc.gnu.o
--- Comment #10 from bangerth at gmail dot com 2010-02-17 01:45 ---
(In reply to comment #9)
> The workaround in Comment #5 does work in mainline.
Right, but that wasn't the question. Does my program in comment #8 work? If
not, then that would be a regression.
As for the workaround in
--- Comment #5 from zsojka at seznam dot cz 2010-02-17 01:07 ---
Testcase from comment #4 still fails in trunk with checking enabled:
$ /mnt/svn/gcc-trunk/binary-156800-lto/bin/gcc -fPIC -shared -flto 1.cpp 2.cpp
3.cpp
header.h:10:20: warning: type of ‘array’ does not match original
dec
--- Comment #21 from paolo dot carlini at oracle dot com 2010-02-17 00:22
---
*** Bug 43100 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-17 00:22
---
*** This bug has been marked as a duplicate of 42983 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-17 00:20
---
The workaround in Comment #5 does work in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-17 00:19 ---
I think this is the same as PR 42983 and there was already a core issue on the
issue of virtual destructor not being able to be defaulted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43100
The following code is compiled with gcc (Gentoo 4.4.3 p1.0) 4.4.3
g++ -std=c++0x -Wall x.cpp
but the output of executing a.out is
*** glibc detected *** ./a.out: free(): invalid pointer: 0x083b4010 ***
Aborted
class Dummy
{
public:
Dummy()
{
}
~Dummy()
{
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-02-16 23:56 ---
No it does not return immediately. You are reading the code so incorrectly
because you forgot to include the exception handling table.
The code difference for the source you provided is the same between 4.4 and the
--- Comment #8 from dan dot colascione at gmail dot com 2010-02-16 23:43
---
Created an attachment (id=19895)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19895&action=view)
bad code
The code generated seems to violate the ABI exception handling specification
here: http://www.co
--- Comment #8 from bangerth at gmail dot com 2010-02-16 23:42 ---
(In reply to comment #6)
> Clarified summary. Since this isn't a regression and there is a workaround,
> it
> doesn't seem like a high priority for 4.5.
But if I understand comment #3 correctly, then the workaround ori
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||error-recovery
Known to work||3.3.6
--- Comment #2 from zsojka at seznam dot cz 2010-02-16 23:33 ---
3.4.6 crashes
3.3.6, 3.2.3 and 2.95 don't crash (and valgrind doesn't report any relevant
errors)
--
zsojka at seznam dot cz changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-16 23:13 ---
Confirmed. Not a regression as far as I can test right now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dan dot colascione at gmail dot com 2010-02-16 23:07
---
Created an attachment (id=19894)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19894&action=view)
Minimal testcase
The leak triggered by the return in the 'catch' statement in current_ex(). I've
brackete
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE: tree check: expected |[4.5 Regression] ICE: tree
|tree that contains 'dec
--- Comment #5 from dan dot colascione at gmail dot com 2010-02-16 22:47
---
But the bug does not appear when compiling with gcc 4.4, which uses the same
unwinder.
--
dan dot colascione at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-02-16 22:47 ---
Oh and on x86_64-linux-gnu with and without -m32, the program does not leak.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-16 22:46 ---
This looks like a bug in Apple's unwinder and not a bug in GCC at all. So I
think you should report this to Apple.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #3 from dan dot colascione at gmail dot com 2010-02-16 22:43
---
Created an attachment (id=19893)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19893&action=view)
valgrind output showing the leak
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43099
--- Comment #2 from dan dot colascione at gmail dot com 2010-02-16 22:41
---
Also, compilation was done with just g++-mp-4.5 -m32 foo.cpp. The leak occurs
at all optimization levels.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43099
--- Comment #1 from dan dot colascione at gmail dot com 2010-02-16 22:40
---
Created an attachment (id=19892)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19892&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43099
The attached small program leaks 425,408 bytes according to valgrind. The leak
does not occur when compiling with gcc 4.4 or any other version of gcc.
Using built-in specs.
COLLECT_GCC=g++-mp-4.5
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-appl
--- Comment #8 from bergner at gcc dot gnu dot org 2010-02-16 20:02 ---
Thanks for the reduced testcase. I'll have a look at what's wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--- Comment #16 from pinskia at gcc dot gnu dot org 2010-02-16 19:57
---
> In this case, the loop itself is "empty" and we can replace every use of the
> phi with "n" (exit value of the iv).
I don't think that is done by remove_empty_loop anyways and it is already done
by sccp (Propaga
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-16 19:54 ---
Reducing a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #15 from changpeng dot fang at amd dot com 2010-02-16 19:54
---
Hello,
I am not sure whether CD-DCE can fully replace remove_empty_loop. However,
I would prefer to keep remove_empty_loop pass. There are two reasons for
this proposal:
(1) remove_empty_loop was at level -O1 an
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in rename_map_elt_info |[4.5 Regression] ICE in
|for Graphite, vect in
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-16 19:45 ---
The ICE only happens on hosts where dividing by zero is an signal which means
it works on powerpc and arm :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-16 19:45 ---
Created an attachment (id=19891)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19891&action=view)
gcc45-pr43092.patch
Different patch where the replacement is done when emitting notes, not early.
This seems to c
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-16 19:43 ---
*** This bug has been marked as a duplicate of 43066 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-16 19:43 ---
*** Bug 43098 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.5 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43098
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from sje at cup dot hp dot com 2010-02-16 18:50 ---
Forgot to mention that the test was added along with a fix for PR c++/41788.
I don't think the fix or the test are bad though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-16 18:49
---
Agreed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
--- Comment #3 from sje at cup dot hp dot com 2010-02-16 18:48 ---
I would guess this failure started with r156088 when the test was added. I
think the test is OK but that ia64 can't handle packing OUTER when one of the
fields in OUTER is a struct with a virtual function.
--
sje at
--- Comment #25 from jason at redhat dot com 2010-02-16 18:43 ---
Subject: Re: NULL (__null) not considered different from 0
with C++
On 02/16/2010 01:27 PM, manu at gcc dot gnu dot org wrote:
> I guess you mean Wconversion-null instead of Wconversion-nul. Fine.
OK with that change.
--- Comment #24 from manu at gcc dot gnu dot org 2010-02-16 18:27 ---
(In reply to comment #23)
> That looks fine to me, though you'll probably want to use "null" instead of
> null in the command line option. :)
>
I guess you mean Wconversion-null instead of Wconversion-nul. Fine.
Any
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-16 18:26 ---
Where the compiler always chooses some particular implementation is
implementation defined behavior, not undefined behavior. Undefined behavior is
always just that, undefined.
--
jakub at gcc dot gnu dot org chang
--- Comment #1 from dominiq at lps dot ens dot fr 2010-02-16 18:18 ---
Confirmed on x86_64-apple-darwin10 revision 156811.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
--- Comment #21 from dominiq at lps dot ens dot fr 2010-02-16 18:13 ---
> Comment #9 suggests you can reproduce this without -frename-registers. Is
> this
> correct?
>From comment #12:
> -funroll-loops triggers -frename-registers which again would hint at
> Bernds change.
I think th
--- Comment #23 from echristo at apple dot com 2010-02-16 18:09 ---
That looks fine to me, though you'll probably want to use "null" instead of
null in the command line option. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
--- Comment #22 from manu at gcc dot gnu dot org 2010-02-16 18:05 ---
Testing this:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 156812)
+++ gcc/doc/invoke.texi (working copy)
@@ -3835,18 +3835,23 @@ lik
--- Comment #21 from echristo at apple dot com 2010-02-16 18:01 ---
I remember that we originally ran into this warning in a huge number of places
building OSX. Now I'd agree that null checking would be something good to
have, but there should be some way to turn it off if it's on by de
GCC (156804, x86_64-unknown-linux-gnu) generates an ICE in compiling the
following code.
typedef __builtin_va_list va_list;
struct __attribute__((aligned (4))) S238 { struct{}a[24]; short b; } ;
struct __attribute__((aligned (4))) S238 a238[5];
extern int fails;
void foo (int z, ...) {
s
--- Comment #6 from pinskia at gmail dot com 2010-02-16 17:51 ---
Subject: Re: Optimizer ignores type in a conversion
Sent from my iPhone
On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"
wrote:
>
>
> --- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail d
Sent from my iPhone
On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"
wrote:
--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com
2010-02-16 17:37 ---
(In reply to comment #4)
There is nothing to fix. Your program triggers undefined
behavior.
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-02-16 17:43
---
(In reply to comment #6)
Looks like this has been fixed. We do generate good code:
fred:
li 0,100
mtctr 0
.L2:
sthu 3,2(4)
bdnz .L2
blr
.size fred, .-fred
--- Comment #1 from laurent at guerby dot net 2010-02-16 17:43 ---
Might be related to the same patch on powerpc-linux two different ACATS started
FAILing around the same time:
LAST_UPDATED: Fri Jan 29 08:20:22 UTC 2010 (revision 156342)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg
--- Comment #20 from bernds_cb1 at t-online dot de 2010-02-16 17:40 ---
Sorry I've seen this so late; the mails I got have been hidden in my unread
fortran folder so far. Need to change the filters.
Comment #9 suggests you can reproduce this without -frename-registers. Is this
correct
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
173.applu on powerpc64-linux with options "-O2 -fgraphite-identity
-ftree-vectorize" for either -m32 or -m64. Here's a minimized testcase:
subroutine foo (ldmx,ldmy,nx,ny,v)
implicit real*8 (a-h, o-z)
dime
--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-16
17:37 ---
(In reply to comment #4)
> There is nothing to fix. Your program triggers undefined behavior. It can do
> anything, which can include something you'd expect, or something completely
> different and it can
The following ACATS started failing:
,.,. C37105A ACATS 2.5 10-02-16 15:35:22^M
C37105A RECORDS WITH ONLY DISCRIMINANTS.^M
* C37105A DISCRIMINANT-ONLY RECORDS DON'T WORK.^M
C37105A FAILED .^M
between:
PASS: LAST_UPDATED: Fri Jan 29 14:43:55 UTC 2010 (revi
--- Comment #20 from jason at gcc dot gnu dot org 2010-02-16 17:10 ---
I would approve a patch to enable the warnings in conversion_null_warnings, and
the similar warning in build_expr_type_conversion, by default. That is,
reverting revision 109847. I don't know what Eric's rationale w
--- Comment #9 from dominiq at lps dot ens dot fr 2010-02-16 17:06 ---
Apparently gfortran.dg/pr41043.f90 has not been committed.
Thanks for the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-16 17:05 ---
>/usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: BFD (GNU
Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4 internal error, aborting at
../../bfd/merge.c line 869 in _bfd_merged_section_offset
usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2 :
(reconfigured) ../configure --prefix=/usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.5.0 20100216 (experimental) (GCC)
--
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-16 16:46 ---
Clarified summary. Since this isn't a regression and there is a workaround, it
doesn't seem like a high priority for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |
Linking CXX executable semnotes
cd /home/pielud/creator/semnotes/build/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/semnotes.dir/link.txt --verbose=1
/usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-
--- Comment #9 from doko at ubuntu dot com 2010-02-16 16:34 ---
confirmed with binutils trunk 20100216, checking with gold from the trunk.
--
doko at ubuntu dot com changed:
What|Removed |Added
--- Comment #5 from jorrit at jorrit dot de 2010-02-16 16:30 ---
Here is a workaround that works with gcc "gcc version 4.1.3 20080704
(prerelease) (Debian 4.1.2-27)" as well as the gcc 3.4 and 4.4 mentioned in
Comment #3.
=
--- Comment #8 from kargl at gcc dot gnu dot org 2010-02-16 16:29 ---
(In reply to comment #6)
> Subject: RE: gfortran: spurious warning of line truncation at col 72
>
> > Well, it's a counting issue. Fixed-form Fortran is required to
> > have exactly 72 characters in a line of code.
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-16 16:27 ---
Created an attachment (id=19890)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19890&action=view)
patch
Incomplete patch I've tried, didn't make any difference unfortunately.
--
http://gcc.gnu.org/bugzilla/
--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-16 16:25 ---
(In reply to comment #3)
> Mystery solved. It is to do with line endings. When gfortran sees
> a file with DOS line endings it interprets the CR and LF as separate
> characters. This is why demonstrating the effect
--- Comment #35 from mikestump at comcast dot net 2010-02-16 16:25 ---
Ok to the last patch for now. Feel free to file a bug about checking
DECL_PRESERVE_P and add a pointer to remove the setting of DECL_ATTRIBUTES from
the frontend, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-16 16:12 ---
"Fixed" on trunk. Let's see if it causes any performance fallout.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-16 16:11 ---
Subject: Bug 41043
Author: rguenth
Date: Tue Feb 16 16:11:28 2010
New Revision: 156808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156808
Log:
2010-02-16 Richard Guenther
PR tree-optimization/
--- Comment #6 from patrick dot wallace at stfc dot ac dot uk 2010-02-16
16:10 ---
Subject: RE: gfortran: spurious warning of line truncation at col 72
> Well, it's a counting issue. Fixed-form Fortran is required to
> have exactly 72 characters in a line of code. Does CRLF count as
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-16 16:08
---
Jason, can we still do something about this? See Comment #3, in particular...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from jorrit at jorrit dot de 2010-02-16 16:03 ---
This still fails with "gcc version 4.3.4 (Debian 4.3.4-6)" and "gcc version
4.4.3 20100108 (prerelease) (Debian 4.4.2-9)"
In addition the workaround suggested in the last comment stopped working for
gcc 4.4
--
jorrit at
--- Comment #5 from kargl at gcc dot gnu dot org 2010-02-16 16:01 ---
(In reply to comment #4)
> Subject: Re: gfortran: spurious warning of line truncation
> at col 72
>
> On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:
>
> > Mystery solved. It is to do with li
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-16 15:46 ---
(In reply to comment #2)
I have just patched a tree with the fix for PR36932 on an i686 at work. None
of these temporaries appear!
Something is different between 32 and 64 bits..
Paul
--
http://gcc.gnu.org/bug
--- Comment #6 from abel at gcc dot gnu dot org 2010-02-16 15:43 ---
How about the below patch? It fixes all testcases for me. I'm not sure
whether it makes sense to filter duplicate labels this late, but I don't know
how to do this earlier, as catches seem to be lowering independently
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43093
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-16 15:17 ---
For sp based addresses in the -fno-var-tracking-assignments case we have
vt_stack_adjustments that replaces the sp based MEMs with CFA based ones
(frame_pointer_rtx resp. arg_pointer_rtx based ones).
Unfortunately, add
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-16 15:06 ---
I can mitigate the effect of VRP calling SCEV somewhat, but still we'll
the following trigger the issue.
int foo (int i)
{
long j = i;
int k = 0;
while (j < 1)
{
j *= i;
j *= j;
j *=
--- Comment #34 from developer at sandoe-acoustics dot co dot uk
2010-02-16 14:58 ---
Created an attachment (id=19889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19889&action=view)
patch with CLASS and SELECTOR refs. marked as TREE_ADDRESSABLE &
DECL_PRESERVE_P (for NeXT runtim
--- Comment #2 from jacek at codeweavers dot com 2010-02-16 14:38 ---
Here is simplified test:
struct S {
int x;
S(const S &s) {}
};
S __attribute__((__stdcall__)) getS();
void test()
{
S s = getS();
}
It seems like calling stdcall function that returns a struct (or class) with
--- Comment #2 from francois dot jacq at irsn dot fr 2010-02-16 14:07
---
Sorry,
this is a duplication of 34640 I found 2 years ago ... It has nothing to do
with BIND(C) but only with "value => d(:)%..." when value is a dummy !
I thought that this bug was already corrected and I did n
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-16 13:51 ---
I think the comment applies only to FLOOR and ROUND - at least when it was
first written those were the only ones present. If I read the source code
correctly, the ME floor(l,f) is not directly called but instead the
--- Comment #3 from miro dot kropacek at gmail dot com 2010-02-16 13:47
---
>It must be hardlinked, not copied, on the systems which support hard links.
I don't know, Linux copies it, too.
>it is an *internal* directory of the toolchain for *internal* use by one
>toolchain binary call
--- Comment #1 from jacek at codeweavers dot com 2010-02-16 13:45 ---
Created an attachment (id=19888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19888&action=view)
Preprocessed nsSVGOuterSVGFrame.cpp
Result of command
$ i686-mingw32-g++ -mno-cygwin -o nsSVGOuterSVGFrame.o -c
686-mingw32
Configured with: ../gcc/configure --prefix=/home/jacek/gcc/mingw
--target=i686-mingw32 --with-gnu-ld --with-gnu-as --enable-__cxa_atexit
target_alias=i686-mingw32 --enable-languages=c,c++
Thread model: win32
gcc version 4.5.0 20100216 (experimental) (GCC)
--
--- Comment #7 from jacek at codeweavers dot com 2010-02-16 13:35 ---
I've confirmed that it's fixed for Mozilla code. Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43031
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc.g
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-16
13:25 ---
> Except from the fact this 'as' is not symlinked but copied
It must be hardlinked, not copied, on the systems which support hard links.
> The fact that the toolchain has various such internal directories
/* { dg-do run } */
/* { dg-options "-O2 -march=i586 -dA -g -fomit-frame-pointer" { target { {
i?86-*-* x86_64-*-* } && ilp32 } } } */
void __attribute__((noinline))
bar (int *p)
{
(*p)++;
asm volatile ("" : "=r" (*p) : "0" (*p) : "memory");
}
void __attribute__((noinline))
baz (int a, int b,
1 - 100 of 153 matches
Mail list logo
