Yes. AFAICT, it's intra .exp concurrency that's causing this.
Now that I think of it, maybe the problem is that file foo_0.c is
going to one job and foo_1.c is going to another?
Diego.
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Hi,
Should this be XFAILed on powerpc64-apple-darwin9?
A patch doing that is essentially preapproved if you can confirm that in
the meanwhile the malloc bug (Radar 3884894) has been fixed for
i386-apple-darwin and not for powerpc64-apple-darwin. Can you do that?
Thanks,
Paolo.
On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek [EMAIL PROTECTED] wrote:
Quality Data
Priority # Change from Last Report
--- ---
P1 13 - 4
Andrew Pinski [EMAIL PROTECTED] wrote on 19/11/2008 20:54:19:
On Wed, Nov 19, 2008 at 10:48 AM, David Edelsohn [EMAIL PROTECTED]
wrote:
On Wed, Nov 19, 2008 at 1:47 PM, Andrew Pinski [EMAIL PROTECTED]
wrote:
On Wed, Nov 19, 2008 at 10:40 AM, David Edelsohn [EMAIL PROTECTED]
wrote:
You
On Thu, Nov 20, 2008 at 1:24 PM, Laurent GUERBY [EMAIL PROTECTED] wrote:
On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek [EMAIL PROTECTED] wrote:
Quality Data
Priority # Change from Last Report
This option has been problematic and does not seem to be well
maintained. In terms of usefulness, it would also be worth
implementing as a gimple pass, ideally in IPA mode. I propose that we
remove it at the next stage 1, at least it will stop causing problems.
Thoughts?
Diego.
On Thu, Nov 20, 2008 at 7:56 AM, Diego Novillo [EMAIL PROTECTED] wrote:
This option has been problematic and does not seem to be well
maintained. In terms of usefulness, it would also be worth
implementing as a gimple pass, ideally in IPA mode. I propose that we
remove it at the next stage
On Thu, Nov 20, 2008 at 11:17:52AM +0100, Paolo Carlini wrote:
Hi,
Should this be XFAILed on powerpc64-apple-darwin9?
A patch doing that is essentially preapproved if you can confirm that in
the meanwhile the malloc bug (Radar 3884894) has been fixed for
i386-apple-darwin and not for
Today I happened across something that made me scratch my head.
Perhaps you can help me understand. Or maybe it's a bug.
ada.h contains the following preprocessor juju:
#ifdef __STDC__
#define CAT(A,B) A##B
#else
#define _ECHO(A) A
#define CAT(A,B) ECHO(A)B
#endif
For the non-__STDC__ case,
hi,
I noticed that a number of benchmarks I use to run to test my library run
about 10% slower with gcc-4.3.1 compared to gcc-4.2.3. Would someone here be
interested on more details, or is this normal ?
Thanks (please forward any reply ro myself since I'm not subscribed)
--
Marco Correia
Hi,
On Wed, 19 Nov 2008, H.J. Lu wrote:
On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
[EMAIL PROTECTED] wrote:
On Tue, 18 Nov 2008, H.J. Lu wrote:
I used malloc to create my arrays instead of creating the in the stack.
My program is working now but it is very slow.
I use
andrew == andrew m goth [EMAIL PROTECTED] writes:
andrew For the non-__STDC__ case, why is the macro called _ECHO on
andrew one line and ECHO on the next?
Given that GNAT can only be compiled with GNAT, I bet the non __STDC__
case has not been exercized for years and can simply be removed.
Hi,
I'm trying to compile a Position Independent Executable with a TLS but
gcc doesn't generate the expected code (at least, what i expect).
Here's an example:
__thread int test_loc;
void func()
{
test_loc = 2;
}
I compile the object with:
CFLAGS=-nostdinc -nostdlib -fno-builtin \
On Thu, Nov 20, 2008 at 7:44 AM, Marco Correia
[EMAIL PROTECTED] wrote:
hi,
I noticed that a number of benchmarks I use to run to test my library run
about 10% slower with gcc-4.3.1 compared to gcc-4.2.3. Would someone here be
interested on more details, or is this normal ?
See
Sent from my iPhone
On Nov 20, 2008, at 4:28 AM, Razya Ladelsky [EMAIL PROTECTED] wrote:
Andrew Pinski [EMAIL PROTECTED] wrote on 19/11/2008 20:54:19:
On Wed, Nov 19, 2008 at 10:48 AM, David Edelsohn [EMAIL PROTECTED]
wrote:
On Wed, Nov 19, 2008 at 1:47 PM, Andrew Pinski [EMAIL
On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
Gcc is using local-exec tls model instead of global-dynamic. The
option -fpie is supposed to act as -fpic though (dixit the manual).
Here is the first problem...
Could you explain the problem with this? The choice of local-exec vs
Manuel Lauss [EMAIL PROTECTED] writes:
Admittedly my understanding of mips assembly is not yet very advanced, am I
missing something or is this a bug?
Well, it's a missed optimisation, certainly. Fortunately,
it's conceptually fairly easy to fix. I'll have a go.
Richard
Snapshot gcc-4.3-20081120 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081120/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Nov 20, 2008 at 11:17:52AM +0100, Paolo Carlini wrote:
Hi,
Should this be XFAILed on powerpc64-apple-darwin9?
A patch doing that is essentially preapproved if you can confirm
that in
the meanwhile the malloc bug (Radar 3884894) has been fixed for
i386-apple-darwin and not for
There has been some discussion here of GCC's reputation and of how to
classify bugs.
This bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
has gradually morphed from a compile-time issue to a space issue; if
it's not fixed for 4.4 (and it appears that it will not be fixed in
that
Hi,
First sorry for crossposting, but someone said I should post here, so
here we go:
I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
codes to mark the code positions where the try block starts / ends and
of the except landing pad. The emitted .eh_frame section is parsed
-Original Message-
From: Diego Novillo [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 5:56 AM
To: gcc@gcc.gnu.org
Subject: [RFC] Remove -frtl-abstract-sequences in 4.5
This option has been problematic and does not seem to be well
maintained. In terms of
2008/11/20 Michael Matz [EMAIL PROTECTED]:
Hi,
On Wed, 19 Nov 2008, H.J. Lu wrote:
On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
[EMAIL PROTECTED] wrote:
On Tue, 18 Nov 2008, H.J. Lu wrote:
I used malloc to create my arrays instead of creating the in the stack.
My program is
On Thu, Nov 20, 2008 at 9:28 PM, Alexey Salmin [EMAIL PROTECTED] wrote:
2008/11/20 Michael Matz [EMAIL PROTECTED]:
Hi,
On Wed, 19 Nov 2008, H.J. Lu wrote:
On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
[EMAIL PROTECTED] wrote:
On Tue, 18 Nov 2008, H.J. Lu wrote:
I used malloc to
--- Comment #23 from rakdver at gcc dot gnu dot org 2008-11-20 08:06
---
Subject: Bug 32283
Author: rakdver
Date: Thu Nov 20 08:05:12 2008
New Revision: 142035
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142035
Log:
PR rtl-optimization/32283
*
--- Comment #13 from bonzini at gnu dot org 2008-11-20 08:48 ---
I agree with Steven that the bug title does not make sense. It is the same as
complaining that IRA has a regression because it disables regmove.
OTOH, this *is* a regression and the bug should stay open. For example, it
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 08:53 ---
so I guess this is up to the front end to generate 'better' code for size
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-11-20 09:19 ---
*** Bug 38187 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38186
--- Comment #1 from schwab at suse dot de 2008-11-20 09:19 ---
*** This bug has been marked as a duplicate of 38186 ***
--
schwab at suse dot de changed:
What|Removed |Added
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:3205 Avoid
unused local variables such as 'ampRead'.
I have checked the source code and I agree.
Suggest remove set
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentHashMap.java:807
Avoid unused local variables such as 'c'.
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-20 09:44 ---
Subject: Bug 38181
Author: jakub
Date: Thu Nov 20 09:42:35 2008
New Revision: 142037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142037
Log:
PR fortran/38181
* trans-intrinsic.c
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1056
Avoid unused local variables such as 'customOptions'.
The source code is
List customOptions = new
--- Comment #63 from rguenth at gcc dot gnu dot org 2008-11-20 10:01
---
The patch looks reasonable. I understand that the warning is enabled by
default
but does not trigger from libstdc++ because that's system headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
gcc-4.4-20081114/libjava/classpath/gnu/javax/security/auth/callback/SwingCallbackHandler.java:302
Avoid unused local variables such as'defaultIndex'.
The source code is
int defaultIndex = 0;
for (int i = 0; i locales.length; i++)
{
localeNames[i+1] =
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
/home/dcb/gcc/20081114/javaExperiment/gcc-4.4-20081114/libjava/classpath/java/util/HashMap.java:749
Avoid unused local variables such as 'dest'.
The source code is
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-20 10:21 ---
With this patch, I got:
$ time ./test1 # 4.4 r142036
real0m3.291s
user0m3.289s
sys 0m0.002s
$ time ./test2 # 4.4 r142037
real0m1.327s
user0m1.325s
sys 0m0.002s
--
--- Comment #64 from paolo dot carlini at oracle dot com 2008-11-20 10:24
---
(assuming I understand correctly Jason' approach - didn't really follow in
detail the thread, lately) let me know if you want me to remove the
exception_defines.h tricks from the library...
--
paolo dot
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/javax/swing/DefaultListSelectionModel.java:300
Avoid unused local variables such as 'end'.
The source code is
int beg = sel.nextSetBit(0), end =
The description of num_put::do_put(bool) function states (22.2.2.2.2):
iter_type do_put(iter_type out, ios_base str, char_type fill, bool val) const;
Effects: If (str.flags()ios_base::boolalpha)==0 then do
out = do_put(out, str, fill, (int)val)
Otherwise do
const numpunct np =
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-20 10:57 ---
Example:
#include iostream
#include locale
using namespace std;
class my_numpunct : public numpunctchar
{
protected:
string do_falsename() const {return -no-;}
};
int main()
{
locale my_loc =
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/tools/gnu/classpath/tools/rmic/ClassRmicCompiler.java:922
Avoid unused local variables such as'endReturnTryCatch'.
The source code is
--- Comment #7 from jv244 at cam dot ac dot uk 2008-11-20 11:03 ---
(In reply to comment #6)
great.. thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/gnu/javax/print/ipp/attribute/supported/JobSheetsSupported.java:138
Avoid unused local variables such as 'j'.
The source code is
int j = 0;
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/javax/swing/table/DefaultTableColumnModel.java:401
Avoid unused local variables such as 'ls'.
The source code is
java.util.ArrayList ls =
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-20 12:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-11-20 12:13 ---
Subject: Bug 37868
Author: rguenth
Date: Thu Nov 20 12:12:01 2008
New Revision: 142040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142040
Log:
2008-11-20 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-11-20 12:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-20 12:15 ---
Fixed.
*** This bug has been marked as a duplicate of 38051 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-11-20 12:15
---
*** Bug 38169 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-20 12:26
---
Subject: Bug 37868
Author: rguenth
Date: Thu Nov 20 12:25:26 2008
New Revision: 142041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142041
Log:
2008-11-20 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-11-20
12:55 ---
The patch in comment 13 appears to be sufficient to completely fix the problem
on i686-apple-darwin9.
The results for current gcc trunk with the patch...
--- Comment #9 from tschwinge at gcc dot gnu dot org 2008-11-20 13:26
---
Fixed on trunk as rev142043.
--
tschwinge at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-20 13:42
---
Ok, let's do this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from mikael at gcc dot gnu dot org 2008-11-20 13:43 ---
Created an attachment (id=16727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16727action=view)
much more manageable testcase
I think the testcase is invalid as both PBit4set and PBit8set contain a
getNullSet
):0.562s
g77 (32bit): 2.786s
gfortran4.3 (64bit): 3.906s
gfortran4.4 (20081120, 64bit): 4.832s
Even worse:
!234567
character buffer*10
integer i,j
DO j=1,
write(buffer,'(i4)') j
write(*,*) buffer(1:4)
read
--- Comment #1 from jb at gcc dot gnu dot org 2008-11-20 14:04 ---
I'm looking at I/O performance as part of PR 25561 (see also PR 37754, perhaps
this is a dup?), but my changes are invasive enough that they are 4.5 material.
Thanks for the report.
--
jb at gcc dot gnu dot org
I found following internal compiler error in gcc trunk rev. 142038,
maybe a regression of bug 38051 fix.
$ gcc-4.4 -O2 -c tst.c
tst.c: In function bar2:
tst.c:20: internal compiler error: in find_func_aliases, at
tree-ssa-structalias.c:3905
Please submit a full bug report,
with preprocessed
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-20 14:33 ---
duplicate of pr36935?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
Both Intel FMA and AMD SSE5 support FMA. For -mfma, which enables
Intel FMA and is a dummy at the moment, or -msse5, we will
generate FMA instructions for
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
What FMA should -mfma -msse5 generate? Also currently, with
-O2 -mavx
--- Comment #2 from ddenisen at altera dot com 2008-11-20 14:57 ---
I searched through all the options in -O2 that are not in -O1 and found that
only one triggers the problem: -fstrict-aliasing.
To summarize, g++ -m32 -O1 a.ii does not cause the problem but g++ -m32 -O1
--- Comment #2 from manfred99 at gmx dot ch 2008-11-20 14:59 ---
The profiling of the second testcase gives
% cumulative self self total
time seconds secondscalls Ts/call Ts/call name
44.20 8.34 8.34 next_char
--- Comment #12 from jakub at gcc dot gnu dot org 2008-11-20 15:08 ---
I think the primary question is, is libgfortran in 4.4 supposed to stay at
libgfortran.so.3? If yes, then it must be backwards compatible with 4.3.
Looking at the 4.3 to 4.4 io.h changes, I see several problems.
--- Comment #3 from ddenisen at altera dot com 2008-11-20 15:10 ---
This could be a duplicate of 35643.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
--- Comment #65 from jason at redhat dot com 2008-11-20 15:14 ---
Subject: Re: exception_defines.h #defines try/catch
No, it doesn't make any sense to use try/catch in a program that you're
planning to build with -fno-exceptions. It does, however, make sense to
use try/catch in a
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-20 15:15 ---
Invalid gimple:
(gdb) call debug_gimple_stmt (origt)
# STORES: { foo_ptr }
foo_ptr ={v} (int (*T4cb) (void * *)) ptr.3_4;
produced by forwprop. Probably caused by Jakubs patch
2008-11-17 Jakub Jelinek [EMAIL
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-20 15:41 ---
Nope, this is very likely a dup of PR29286.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:52 ---
Other compilers have the SHARE= specifier for OPEN and INQUIRE, e.g. Intel or
HP. I'm not sure it is needed, but one could consider supporting it as well
when implementing this option.
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:56 ---
Jerry, regarding the suggestion in comment 2: Do you see that we can do there
some optimization, esp. when reading a number or with * a string (for '(a)'
one presumably cannot do any optimization and has to read past
--- Comment #5 from hjl at gcc dot gnu dot org 2008-11-20 15:56 ---
Subject: Bug 37859
Author: hjl
Date: Thu Nov 20 15:55:30 2008
New Revision: 142047
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142047
Log:
2008-11-20 H.J. Lu [EMAIL PROTECTED]
Backport from
--- Comment #3 from paolo at gcc dot gnu dot org 2008-11-20 16:01 ---
Subject: Bug 38196
Author: paolo
Date: Thu Nov 20 16:00:17 2008
New Revision: 142048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142048
Log:
2008-11-20 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-20 16:02
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
New test gcc.dg/torture/pr37868.c fails for -O[0123s] with:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr37868.c:8: error:
width of 'a' exceeds its type
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr37868.c:9: error:
width of 'b' exceeds its type
The test contains these
--- Comment #1 from eric dot weddington at atmel dot com 2008-11-20 16:14
---
Test was added by:
2008-11-20 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/37868
* gcc.dg/torture/pr37868.c: New testcase.
* gcc.c-torture/execute/pr38048-1.c: Likewise.
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-11-20 16:25
---
Reduced testcase for the libgfortran failure (-O2 -ftree-vectorize):
void matmul_i4 (int * __restrict dest_y,
const int * __restrict abase,
const int * __restrict bbase_y,
(value)),*) i
write(*,*) i
ENDDO
end program internalread3
gfortran4.4 (20081120, 64bit): 1.079s
i.e. speedup by factor 23 ...
but there are cases where the user can't solve the issue like this.
And such basic optimizations are more efficiently done
by the compiler.
Besides
A small testcase:
#include stdlib.h
extern unsigned int whatever(unsigned char *);
__attribute__((noreturn)) int main(void)
{
whatever(NULL);
for(;;);
}
If you compile this code without -mthumb, gcc asm output is as such:
.file pqp.c
.text
.align 2
.global
--- Comment #41 from hjl dot tools at gmail dot com 2008-11-20 16:44
---
You may want to take a look at PR 36159.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dwarak dot rajagopal at amd dot com 2008-11-20 16:48
---
1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions).
So having -msse5 -mfma is same as having just msse5, though you can just
have -fma (without -msse5).
2) -mavx -msse5 = Yes. This
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-11-20 16:52
---
Created an attachment (id=16728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728action=view)
A more involved testcase.
This testcase shows the preserving behaviour on multiple call-clobbered
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-20 16:57 ---
(In reply to comment #1)
1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions).
So having -msse5 -mfma is same as having just msse5, though you can just
have -fma (without -msse5).
Please
For this function:
int test (int a, int b, int c, int g)
{
int d, e;
if (a)
d = b * c;
else
d = b - c;
e = b * c + g;
return d + e;
}
the multiply expression is moved to both branches of the if, it would be
better to move it before the if. Intel's compiler does that.
--
--- Comment #32 from ro at gcc dot gnu dot org 2008-11-20 17:11 ---
Subject: Bug 33100
Author: ro
Date: Thu Nov 20 17:09:53 2008
New Revision: 142049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142049
Log:
gcc:
PR bootstrap/33100
* config.gcc
--- Comment #33 from ro at gcc dot gnu dot org 2008-11-20 17:14 ---
Subject: Bug 33100
Author: ro
Date: Thu Nov 20 17:13:01 2008
New Revision: 142050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142050
Log:
gcc:
PR bootstrap/33100
* config.gcc
--- Comment #34 from ro at techfak dot uni-bielefeld dot de 2008-11-20
17:14 ---
Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad
cie version 0: offset 0x0
Fixed for 4.3.3, 4.4.0:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00990.html
--
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-11-20 17:15
---
The problem with our restrict handling seems to be deeper. We fail to set
the based-on-restrict property properly.
abase_n{4}_13 = abase{-2}_12(D) + D.1614_11;
so here abase_n and abase are not properly
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-11-20 17:22
---
For 4.4 I will collect the fixes and just disable the assertion... we cannot
fix this properly without switching to a completely points-to based restrict
implementation (lumping restrict together with TBAA info
--- Comment #35 from ro at gcc dot gnu dot org 2008-11-20 17:33 ---
Fixed for all active release branches.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #66 from hhinnant at apple dot com 2008-11-20 17:40 ---
(In reply to comment #65)
Subject: Re: exception_defines.h #defines try/catch
No, it doesn't make any sense to use try/catch in a program that you're
planning to build with -fno-exceptions. It does, however,
--- Comment #3 from dojo at masterleep dot com 2008-11-20 17:55 ---
Oops, sorry for missing that. Thank you for the help. I was led astray
because for mysterious reasons it always worked before...
--
dojo at masterleep dot com changed:
What|Removed
--- Comment #67 from mmitchel at gcc dot gnu dot org 2008-11-20 17:55
---
I think that the current libstdc++ behavior is undesirable, for the reasons
that Howard says. In particular, the fact that including a libstdc++ header
can result in definitions of try and catch as macros is
--- Comment #68 from jason at redhat dot com 2008-11-20 18:10 ---
Subject: Re: exception_defines.h #defines try/catch
mmitchel at gcc dot gnu dot org wrote:
If I recall correctly, unwinding into a frame with no EH data will cause a
runtime abort, so programs will not silently skip
--- Comment #5 from sje at cup dot hp dot com 2008-11-20 18:30 ---
The limits-fnargs.c tests pass on my IA64 platforms (HP-UX and Linux). It
still failed on hppa64-*-hpux* with a timeout but my PA box is quite slow and I
have other tests timing out there as well. I am willing to call
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-20 18:42 ---
Subject: Bug 37540
Author: jason
Date: Thu Nov 20 18:40:52 2008
New Revision: 142054
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142054
Log:
PR c++/37540
* call.c (build_over_call): Take the
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-20 18:42 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2008-11-20
18:43 ---
Still happens with 4.4.0:
qqq (int a)
{
int result.0;
int D.1236;
int result;
result.0 = bar (a);
result = result.0;
D.1236 = result;
return D.1236;
}
--
dann at godzilla dot ics dot
--- Comment #1 from dnovillo at gcc dot gnu dot org 2008-11-20 18:47
---
Subject: Bug 38178
Author: dnovillo
Date: Thu Nov 20 18:45:58 2008
New Revision: 142055
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142055
Log:
2008-11-20 Rafael Espindola [EMAIL PROTECTED]
.ident GCC: (GNU) 4.4.0 20081120 (experimental) [trunk revision
142045]
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED] gcc]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 18:54 ---
(In reply to comment #3)
duplicate of pr36935?
similar enough to make this one depend on PR36935. I think the testcases here
(certainly comment #1), are more difficult.
--
jv244 at cam dot ac dot uk changed:
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-20
18:59 ---
Subject: Re: limits-fnargs.c takes very long time to compile at -O2
--- Comment #5 from sje at cup dot hp dot com 2008-11-20 18:30 ---
The limits-fnargs.c tests pass on my IA64 platforms (HP-UX
1 - 100 of 150 matches
Mail list logo
