Moreover, our contribute page says the GCC maintainer that is
taking care of your contributions and there is no documentation
to maintainers, so that part at least is wrong: maintainers don't
know what to do. Or else, I just didn't receive the maintainer
welcome package including the
Then I suggest changing our contribute page from
contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer
that is taking care of your contributions) to obtain the relevant forms
to
contact us (either via the gcc@gcc.gnu.org list or a GCC Steering
Commitee member) to obtain the
On Mon, 7 Apr 2008, DJ Delorie wrote:
I will apply the following if you confirm this fixes m32c-elf.
It fixed that particular bug, but another one elsewhere stopped the
build and I don't know what caused the other one.
m32c-elf is easily cross-build with newlib and binutils if you want
On Thu, Apr 3, 2008 at 8:28 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
On Thu, Apr 3, 2008 at 7:35 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
Say the target has two delay slots for call
Mark Mitchell wrote on :
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
Apparently, IAR's Atmel AVR compiler does this optimization as well.
Say, how do I get gcc to actually do this? I can't reproduce this in a
real-world test. I would
Dear gcc developers,
I have found a weird discrepancy in error/warning reporting in
GCC4.x. The following fragment:
enum e { A, B, C };
struct u { enum e e:2; };
void bar(struct u u) {
switch (u.e) {
case A:;
}
}
It does (rightfully) trigger a -Wswitch warning on gcc-3.3
On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote:
~ $ gcc -O3 -S -xc -o 2.s -
extern void foo (char *buf, int len);
extern void bar (char *buf);
void foo (char *buf, int len)
{
if (buf+len buf)
{
bar (buf);
}
return;
}
Note that if buf is a char *, there's no
On Mon, Apr 07, 2008 at 02:15:14PM -0400, Robert C. Seacord [EMAIL
PROTECTED] wrote:
The advisory suggests that people not use GCC.
no, it does not. it suggests they may not want to use the latest
versions. this is one possible work around. we never say use another
compiler.
Yes, it
Hi,
Consider the attached testcase.
Working on a private port (Infact I see this problem on
arm-none-eabi-gcc too). I see the following in test.c.003t.original
fail = (short int) usi = ssi;
And then in test.c.025t.ssa
usi.2_5 = (short int) usi_4;
fail.3_6 = usi.2_5 = ssi_2;
Now ccp1 does
Mohamed Shafi [EMAIL PROTECTED] writes:
Like you said i tried to split the move_immediate pattern after
reload. This is how i did this :
(define_split
[(set (match_operand:HI 0 register_operand )
(match_operand:HI 1 immediate_operand ))]
reload_completed
[(set (match_dup 0)
On Tue, Apr 8, 2008 at 2:32 PM, Pjotr Kourzanov
[EMAIL PROTECTED] wrote:
Dear gcc developers,
I have found a weird discrepancy in error/warning reporting in
GCC4.x. The following fragment:
enum e { A, B, C };
struct u { enum e e:2; };
void bar(struct u u) {
switch (u.e) {
On Tue, Apr 8, 2008 at 4:46 PM, Pranav Bhandarkar
[EMAIL PROTECTED] wrote:
Hi,
Consider the attached testcase.
Working on a private port (Infact I see this problem on
arm-none-eabi-gcc too). I see the following in test.c.003t.original
fail = (short int) usi = ssi;
And then in
Mohamed Shafi wrote:
'liu' will load the immediate value into the upper byte of the
specified register. The lower byte of the register is unaffected.
The liu pattern should be something like
(set (regX) (ior:HI (and:HI (regX) (const_int 255)) (const_int Y)))
Jim
dck 4008
nRLSKwG 653394
EZGO 559
QjgknRLSKwGdOwMp 4329040
krAQjgknRL 912265339432904055
AQjgknRLSKwGd 5339432904055940
Daniel Jacobowitz wrote:
On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote:
~ $ gcc -O3 -S -xc -o 2.s -
extern void foo (char *buf, int len);
extern void bar (char *buf);
void foo (char *buf, int len)
{
if (buf+len buf)
{
bar (buf);
}
return;
}
Note that if buf is a char
Mark Mitchell wrote:
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
Apparently, IAR's Atmel AVR compiler does this optimization as well.
That CPU has 16-bit addresses, so the tester changed the test case to
use 1 14 instead of 1 30.
I've also
Mark,
I will update the CERT C Secure Coding rule with a list of compilers,
once we complete a fact check. Chad is responsible for updating the vul
note, so I'll need to discuss this with him.
Specifically with regards to MSVC 2005, I thought Chad had already
checked this and found that it
Robert C. Seacord wrote:
I will update the CERT C Secure Coding rule with a list of compilers,
once we complete a fact check. Chad is responsible for updating the vul
note, so I'll need to discuss this with him.
Thanks.
Specifically with regards to MSVC 2005, I thought Chad had already
Robert C. Seacord wrote on :
Specifically with regards to MSVC 2005, I thought Chad had already
checked this and found that it did not exhibit this behavior. I just
tested the following program.
#include stdio.h
void f(char *buf) {
unsigned int len = len = 0xFF00;
I'm sure
Kenneth Zadeck wrote:
The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions.
If you want to take on doing this kind of extension, be prepared for
the additional cost.
Kenny, do you have any pointers to
* Richard Kenner:
This is probably true for a country like the USA, but like FX
the FSF didn't ask a disclaimer from my employer: in France
as long as you don't use your employer ressources to contribute
your employer has absolutely no say on what you do outside your work.
That's true in
* Robert C. Seacord:
I agree with you that the behavior that gcc exhibits in this case is
permitted by the ISO/IEC 9899:1999 C specification
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
(ยง6.5.6p8). I believe the vulnerability is that gcc may *silently*
discard the overflow
Mark Mitchell wrote:
Kenneth Zadeck wrote:
The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions.
If you want to take on doing this kind of extension, be prepared for
the additional cost.
Kenny, do you have any
Hi,
I'm working on a GCC (4.3.0) backend for a custom 16 bit microcontroller
we're designing at work, and I'm facing a reload problem. After having
lost many hours trying to make it work, I decided to ask for some
help :)
I'll try to summarize the situation below, but by all means please ask
for
On Tue, Apr 8, 2008 at 5:36 PM, Richard Guenther
[EMAIL PROTECTED] wrote:
On Tue, Apr 8, 2008 at 4:46 PM, Pranav Bhandarkar
[EMAIL PROTECTED] wrote:
Hi,
Consider the attached testcase.
Working on a private port (Infact I see this problem on
arm-none-eabi-gcc too). I see
H.J. Lu wrote:
We will implement meta intrinsic header file for AVX intrinsics.
However, I am not sure if ia32intrin.h is the best name for it.
Does anyone have any suggestions, how about x86intrin.h?
I think there's value in using the same name as icc. It's set a
precedent, let's keep it.
Dave,
I made at least one change you suggested:
#include stdio.h
void f(char *buf) {
unsigned int len = 0xFF00u;
if (buf+len buf) puts(true);
}
int main(void) {
char buffer[100];
printf(buffer addr = %p.\n, buffer);
f(buffer);
return 0;
}
And compiled with flags:
/O2
Jim Wilson wrote:
Wirawan Purwanto wrote:
I tried to compile GCC 4.3.0 on a Red Hat Linux 9.0 box, it stopped at
stage 1:
Compiling new gcc versions on old linux versions may not always work,
and is unlikely to be fixed. You are probably on your own here if you
run into a non-trivial
Take at look at AVR target which is very similar.
Here onluy d constrained register accept constants (they are call used
registers too)
The AVR move pattern (*reloadinqi) has multiple constrain options d
against i being relevant. So check you have all the combinations
defined. You omitted i
On Tue, Apr 08, 2008 at 04:46:16PM -0700, Mark Mitchell wrote:
Jim Wilson wrote:
Wirawan Purwanto wrote:
I tried to compile GCC 4.3.0 on a Red Hat Linux 9.0 box, it stopped at
stage 1:
Compiling new gcc versions on old linux versions may not always work,
and is unlikely to be fixed. You
Continuation of the last one, different bug, building libstdc++ ...
Look familiar to anyone? If not, I'll try to hunt down the cause.
The culprit is this line:
D.25530 = (unsigned int) D.25529;
For m32cm, int is 16 bits, long is 32 bits, and void* is 24
bits. A cast to unsigned int
H.J. Lu wrote:
Icc and gcc will use the same filename. The question is what filename
to use.
Oh, OK. If we get to pick, then, yes, I think x86intrin.h is nice.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kenneth Zadeck wrote:
Mark Mitchell wrote:
Kenneth Zadeck wrote:
The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions.
If you want to take on doing this kind of extension, be prepared for
the additional cost.
--- Comment #1 from ubizjak at gmail dot com 2008-04-08 06:37 ---
Caused by:
http://gcc.gnu.org/viewcvs?view=revrevision=133985,
this particular change:
http://gcc.gnu.org/viewcvs/trunk/gcc/rtlanal.c?r1=133985r2=133984pathrev=133985
--
ubizjak at gmail dot com changed:
--- Comment #47 from ubizjak at gmail dot com 2008-04-08 06:39 ---
Author: bergner
Date: Mon Apr 7 17:36:59 2008
New Revision: 133985
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133985
Log:
PR middle-end/PR28690
* rtlanal.c: Update copyright years.
--- Comment #48 from ubizjak at gmail dot com 2008-04-08 06:43 ---
(In reply to comment #47)
* rtlanal.c: Update copyright years.
(commutative_operand_precedence): Give SYMBOL_REF's the same precedence
This change causes regression in i686-pc-linux-gnu testsuite:
--- Comment #23 from charlet at gcc dot gnu dot org 2008-04-08 06:46
---
Subject: Bug 10768
Author: charlet
Date: Tue Apr 8 06:46:04 2008
New Revision: 134013
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134013
Log:
2008-04-08 Tristan Gingold [EMAIL PROTECTED]
PR ada/10768
--- Comment #24 from charlet at gcc dot gnu dot org 2008-04-08 07:25
---
Fixed on mainline.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Since revision 133942 (not in rev. 133901), I see the following errors:
ERROR: gcc.dg/pr30957-1.c: no files matched glob pattern
hard_float14476.c.[0-9][0-9][0-9]r.expand for dg-require-effective-target 8
hard_float
ERROR: gcc.dg/var-expand1.c: can't read et_cache(hard_float,value): no such
--- Comment #3 from gcc at cohi dot at 2008-04-08 08:31 ---
Created an attachment (id=15445)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15445action=view)
Here's the preprocessed source for a similar bug that might be related.
g++-mp-4.3 -save-temps -I. -std=gnu++0x
--
gcc at cohi dot at changed:
What|Removed |Added
Severity|major |blocker
Summary|ICE on template-heavy C++ |ICEs in template-heavy
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-08 08:41 ---
(In reply to comment #1)
Mostly fixed by the check in for PR 25829.
Missing: Some clean up, INQUIRE, round=, and encoding=.
Follow up: PR 35863, PR 35862
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
--- Comment #4 from burnus at gcc dot gnu dot org 2008-04-08 08:36 ---
(In reply to comment #3)
Another thing I just noticed is that dummy procedures are currently not
checked
for being called with the right arguments (- compare_actual_formal),
If we are lucky this fixes PR 35831.
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-08 08:49 ---
The front-end parsing and translation are completed.
Except for the r* edit descriptors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
--- Comment #8 from rguenther at suse dot de 2008-04-08 08:42 ---
Subject: Re: [4.3 Regression] -funroll-loops breaks inline
float divide
On Mon, 7 Apr 2008, wilson at gcc dot gnu dot org wrote:
--- Comment #7 from wilson at gcc dot gnu dot org 2008-04-07 23:48
---
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-08 09:20 ---
Confirm. Something really goes wrong here, but fortunately it is only a warning
and not an (invalid) error message.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-08 09:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenther at suse dot de|
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-08 10:04 ---
We'll not be able to fix this for 4.3 (the regression is caused by a
correctness
fix), but 4.4 will have this param setting as default.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-08 10:02 ---
*** This bug has been marked as a duplicate of 30908 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-04-08 09:28
---
Created an attachment (id=15446)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15446action=view)
Testcase.
To be compiled at -O2 -gnatp for x86 targets.
--
The to-be-attached Ada testcase exhibits a problem with the switch statement
optimization recently added to VRP:
PR tree-optimization/14495
PR tree-optimization/34793
* tree-vrp.c (struct switch_update): New structure.
(to_remove_edges, to_update_switch_stmts): New
--- Comment #4 from gcc at cohi dot at 2008-04-08 10:55 ---
The second example could be related with a recursive template, more precisely
the templates seq_min_impl1 and seq_min_impl2 together perform a template
meta-programming recursive walk of a template structure, in order to define
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-08 09:55 ---
Subject: Bug 35834
Author: rguenth
Date: Tue Apr 8 09:53:52 2008
New Revision: 134090
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134090
Log:
2008-04-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-04-08 10:02
---
*** Bug 35861 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2008-04-08 09:39 ---
Heh, see http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00623.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35867
--- Comment #19 from eres at il dot ibm dot com 2008-04-08 11:07 ---
The easiest would be to use .cfi_* assembler directives that recentish gas
supports and emitting them inline in the code, rather than creating separate
.eh_frame.
I apologize ahead if I am totally wrong about it
--- Comment #20 from jakub at gcc dot gnu dot org 2008-04-08 11:13 ---
Please read the documentation about .cfi_* directives. They construct an
.eh_frame section for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
--
Summary: write(*,*), 'teste' does not give error
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Not sure if it is a bug, at least is a situation in which
we would expect a error message:
write(*,*), 'test'
The , after the closing quote is not noticed by the compiler.
I've noticed some error like this in my codes after recompiling
with the intel fortran compiler.
Leandro.
--
--
leandromartinez dot spam at gmail dot com changed:
What|Removed |Added
Severity|normal |trivial
--- Comment #1 from leandromartinez dot spam at gmail dot com 2008-04-08
11:32 ---
Wrong submission of bug.
--
leandromartinez dot spam at gmail dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-08 12:00 ---
(In reply to comment #0)
Not sure if it is a bug, at least is a situation in which
we would expect a error message:
write(*,*), 'test'
The , after the closing quote is not noticed by the compiler.
If you care
--- Comment #23 from d at domob dot eu 2008-04-08 13:11 ---
(In reply to comment #22)
However, I'm not quite sure about some things I did [...]
I think your patch is in a good enough shape to post it to [EMAIL PROTECTED]
and ask there for comments; this ensures that all
--- Comment #3 from bergner at gcc dot gnu dot org 2008-04-08 14:47 ---
That hunk has been reverted:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00650.html
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from bergner at gcc dot gnu dot org 2008-04-08 14:49
---
The offending hunk has been reverted in revision 134095.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #4 from dominiq at lps dot ens dot fr 2008-04-08 15:06 ---
My understanding of gcc_assert is that it is meant to trigger ICEs for
forbidden paths. Hence introducing new gcc_assert is likely to trigger ICEs,
including during bootstrap, either because of a rampant bug or
--- Comment #8 from eric dot weddington at atmel dot com 2008-04-08 15:14
---
Commit from Andy fixes the bug.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2008-04-08 15:14 ---
I don't see the failure on (powerpc|i686)-apple-darwin9 nor in
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00549.html. So it does not
seem to affect all platforms.
--
--- Comment #10 from eric dot weddington at atmel dot com 2008-04-08 15:16
---
Andy, since this was a 4.3 regression is there any way we can back port this
and commit it on the 4.3 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
--- Comment #50 from bonzini at gnu dot org 2008-04-08 15:00 ---
I guess that you had modified the precedences in order to allow additional
simplifications. Can you report here what is missed using the current values?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #5 from aj at gcc dot gnu dot org 2008-04-08 15:35 ---
Bootstrap fails on powerpc64-suse-linux-gnu with bootstrapping the 64-bit
compiler as well at the same place.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839
--- Comment #2 from bergner at gcc dot gnu dot org 2008-04-08 15:41 ---
An updated patch (minus the rtlanal.c which has since been reverted) has fixed
this problem.
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg02044.html
--
bergner at gcc dot gnu dot org changed:
What
A 32bit multiplication by a constant results in incorrect code when compiled
for some AVR models (probably those having a hardware multiplier).
Command:
avr-gcc -mmcu=attiny25 -Os -S t1.c (correct)
avr-gcc -mmcu=atmega16 -Os -S t1.c (incorrect)
--
Summary: [4.1
--- Comment #1 from a dot kaiser at gmx dot net 2008-04-08 16:12 ---
Created an attachment (id=15447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15447action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872
--- Comment #2 from a dot kaiser at gmx dot net 2008-04-08 16:12 ---
Created an attachment (id=15448)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15448action=view)
assembly output for tiny25
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872
--- Comment #3 from a dot kaiser at gmx dot net 2008-04-08 16:13 ---
Created an attachment (id=15449)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15449action=view)
assembly output for mega16
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872
-- discovered error with gcc 4.2.1
-- fetched newest gcc binary (4.4.0): error persists
-- my system: openSuse 10.3 Linux i686 (Pentium 4)
-- gcc -malign-double test.f; a.out # ERROR: Segmentation violation
-- gcc test.f; a.out # OK
-- test.f:
program test
character*20 wrkmem
--- Comment #1 from hjj at ifk dot sdu dot dk 2008-04-08 16:47 ---
(In reply to comment #0)
-- gfortran -malign-double test.f; a.out # ERROR: Segmentation violation
-- gfortran test.f; a.out # OK
Fix of typo (gcc instead of gfortran)
--
--- Comment #7 from pluto at agmk dot net 2008-04-08 16:50 ---
(In reply to comment #6)
We'll not be able to fix this for 4.3 (the regression is caused by a
correctness
fix), but 4.4 will have this param setting as default.
Can i safely set this parameter to zero for vendor gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-08 16:51 ---
This is not a bug, -malign-double changes the ABI.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hutchinsonandy at aim dot com 2008-04-08 17:23 ---
Subject: Re: [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c
fails with -O1, -O2 and -Os
I believe the rules allow for this after a suitable grace period.
Remind me towards end of week and I will post for
Hi,
compiling the attached code with
arm-elf-gcc -c compile-delta.i -mthumb -O2
fails with
compile-delta.i: In function 'FlattenIfStatementsStmt':
compile-delta.i:94: internal compiler error: in emit_cmp_and_jump_insn_1, at
optabs.c:4425
--
Summary: Error in
--- Comment #1 from mstein dot lists at googlemail dot com 2008-04-08
17:47 ---
Created an attachment (id=15450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15450action=view)
from csibe, delta-reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35874
--- Comment #3 from jason at gcc dot gnu dot org 2008-04-08 17:50 ---
Subject: Bug 35734
Author: jason
Date: Tue Apr 8 17:49:56 2008
New Revision: 134099
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134099
Log:
PR c++/35734
* class.c
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-08
17:56 ---
Fixed.
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #4 from eric dot weddington at atmel dot com 2008-04-08 18:06
---
Works for 4.2.2 (WinAVR 20071221)
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #5 from eric dot weddington at atmel dot com 2008-04-08 18:16
---
Confirmed on WinAVR 20080407 (gcc 4.3.0 plus patches).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872
Hi,
I get many errors that fail like this:
Executing on host: /home/mstein/sim/ira/sparc-elf/build/gcc/xgcc
-B/home/mstein/sim/ira/sparc-elf/b
uild/gcc/ -O2 -w -fno-show-column -c-fira -o 20011130-2.o
/home/mstein/svn/ira/gcc/testsuite
/gcc.c-torture/compile/20011130-2.c(timeout = 300)
--- Comment #1 from mstein dot lists at googlemail dot com 2008-04-08
18:44 ---
update summary
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #51 from bergner at gcc dot gnu dot org 2008-04-08 18:50
---
Ok, I dug into this a little deeper. For the following test case:
int array[1024];
void
clear_table (unsigned int n)
{
unsigned int i;
for (i = 0; i n; i++)
array[i] = 0;
}
compiling
--- Comment #3 from hjj at ifk dot sdu dot dk 2008-04-08 18:50 ---
I don't understand how you can call it not a bug when a flag (no matter that it
changes the ABI) makes valid fortran code not work
It did work under earlier versions of gfotran.
--
hjj at ifk dot sdu dot dk
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-08 18:54 ---
(In reply to comment #3)
I don't understand how you can call it not a bug when a flag (no matter that
it
changes the ABI) makes valid fortran code not work
You have to compile all of libgfortran with
--- Comment #52 from bonzini at gnu dot org 2008-04-08 19:07 ---
Subject: Re: [4.2 Regression] Performace problem with
indexed load/stores on powerpc
Index: explow.c
===
--- explow.c(revision 134095)
+++
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-04-08 20:05
---
I see it on x86-64 Linux clearly enough and with -m32 and -m64. I think Paul
removed a check that we have to put back in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #6 from eric dot weddington at atmel dot com 2008-04-08 20:38
---
Andy's combine.c patch for bug #35519 fixes this bug. This means that 4.3.0 is
useless for the avr port until that patch is backported.
--
eric dot weddington at atmel dot com changed:
What
Basic exception example:
#include iostream
#include string
using namespace std;
int main() {
try {
throw string(String);
} catch (string s) {
cout Caught an exception \ s \\n;
}
}
Compiled with:
g++ -fexceptions -Wall -o exception exception.cpp
Prints:
terminate called after
--- Comment #1 from jaydub66 at gmail dot com 2008-04-08 20:58 ---
Tobias,
I can confirm the behaviour you described for this test case, provided of
course that one and two are implemented somewhere externally. Otherwise one
gets
undefined reference to `two_'
because there is only an
consider the following program
program short_test_inf
complex*16 nan_inf, normal_number, cmplx_test
real*8 tth, pi, zero
data tth /6.7D-01/
data pi /3.1415926535897932385D0/
data zero /0.0D0/
normal_number = dcmplx(tth,
1 - 100 of 124 matches
Mail list logo
