[Bug target/10768] ICEs on compilation of ada support library for avr

[charlet at gcc dot gnu dot org]

--- 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

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768

[Bug testsuite/35868] New: Errors with hard_float

[dominiq at lps dot ens dot fr]

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
element in array for " dg-require-effective-target 4 hard_float "

Any idea?


-- 
   Summary: Errors with hard_float
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35868

[Bug c++/35828] ICE on template-heavy C++ code, reported in innocent source line

[gcc at cohi dot at]

--- 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=15445&action=view)
Here's the preprocessed source for a similar bug that might be related.

> g++-mp-4.3 -save-temps -I. -std=gnu++0x -D_REENTRANT -pipe -g -O3 -Wall 
> -Wextra -Wimplicit -Wconversion -Wcast-align -Woverloaded-virtual 
> -Wold-style-cast -Wformat=2 -Wswitch-enum -Wswitch-default -Wredundant-decls 
> -fno-enforce-eh-specs -fno-strict-overflow -lpthread scheme.cc -o scheme
g++-mp-4.3: warning: -pipe ignored because -save-temps specified
./rules_generic.hh: In instantiation of
'pegtl::seq_min_impl1,
scheme::comment_text>':
./rules_generic.hh:199:   instantiated from 'const size_t
pegtl::seq_min_impl2, scheme::nested_comment,
scheme::comment_text>::min'
./rules_generic.hh:211:   instantiated from 'const size_t
pegtl::seq_min_impl1,
scheme::comment_text>::min'
./rules_generic.hh:223:   instantiated from 'const size_t
pegtl::seq::min'
./rules_generic.hh:104:   instantiated from 'pegtl::star'
./parse_debugger.hh:214:   instantiated from 'bool
pegtl::trace_debug::match(Input&, Class&& ...) [with Rule =
pegtl::star, Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Class = ]'
./rules_generic.hh:242:   instantiated from 'static bool pegtl::seq::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
pegtl::star, Rules = pegtl::string<124, 35>]'
./rules_generic.hh:242:   instantiated from 'static bool pegtl::seq::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
scheme::comment_text, Rules = pegtl::star,
pegtl::string<124, 35>]'
./parse_debugger.hh:214:   instantiated from 'bool
pegtl::trace_debug::match(Input&, Class&& ...) [with Rule =
pegtl::seq,
pegtl::string<124, 35> >, Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Class = ]'
./rules_generic.hh:242:   instantiated from 'static bool pegtl::seq::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
pegtl::seq,
pegtl::string<124, 35> >, Rules = ]'
./rules_generic.hh:242:   instantiated from 'static bool pegtl::seq::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
pegtl::string<35, 124>, Rules = pegtl::seq, pegtl::string<124, 35> >]'
./parse_debugger.hh:227:   instantiated from 'bool
pegtl::trace_debug::match(bool, Input&, Class&& ...) [with Rule =
scheme::nested_comment, Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Class = ]'
./rules_generic.hh:183:   instantiated from 'static bool pegtl::sor::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
scheme::nested_comment, Rules = pegtl::seq,
scheme::interlexeme_space, scheme::datum>, pegtl::string<35, 33, 114, 54, 114,
115>]'
./rules_generic.hh:183:   instantiated from 'static bool pegtl::sor::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
pegtl::seq, pegtl::until_eol>, Rules = scheme::nested_comment,
pegtl::seq, scheme::interlexeme_space, scheme::datum>,
pegtl::string<35, 33, 114, 54, 114, 115>]'
./parse_debugger.hh:227:   instantiated from 'bool
pegtl::trace_debug::match(bool, Input&, Class&& ...) [with Rule =
scheme::comment, Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Class = ]'
./rules_generic.hh:183:   instantiated from 'static bool pegtl::sor::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
scheme::comment, Rules = ]'
./rules_generic.hh:183:   instantiated from 'static bool pegtl::sor::s_match(Input&, Debug&, Class&& ...) [with Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::ascii_location>, Debug = pegtl::trace_debug, Class = , Rule =
scheme::whitespace, Rules = scheme::comment]'
./parse_debugger.hh:227:   instantiated from 'bool
pegtl::trace_debug::match(bool, Input&, Class&& ...) [with Rule =
scheme::interlexeme_space, Input =
pegtl::iterator_input<__gnu_cxx::__normal_iterator, std::allocator > >,
pegtl::a

[Bug c++/35828] ICEs in template-heavy C++0x code

[gcc at cohi dot at]

-- 

gcc at cohi dot at changed:

   What|Removed |Added

   Severity|major   |blocker
Summary|ICE on template-heavy C++   |ICEs in template-heavy C++0x
   |code, reported in innocent  |code
   |source line |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828

[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=

[burnus at gcc dot gnu dot org]

--- 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

[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments

[burnus at gcc dot gnu dot org]

--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830

[Bug libfortran/35862] [F2003] Implement new rounding modes for run time

[burnus at gcc dot gnu dot org]

--- 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

[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide

[rguenther at suse dot de]

--- 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 
> ---
> Anyone care whether this gets fixed in 4.3?  If so, are you willing to test 
> it?
>  I'll approve it for 4.3 with proper testing, which is not easy for me to do.

We have it patched in in our 4.3 tree and it didn't cause problems sofar,
so I think it should be applied for 4.3 as well.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695

[Bug fortran/35865] Spurious warning for vector-valued functions passed as arguments

[burnus at gcc dot gnu dot org]

--- 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 |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-04-08 09:20:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35865

[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403

[rguenth at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834

[Bug tree-optimization/35869] ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization

[rguenth at gcc dot gnu dot org]

-- 

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 gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-08 09:56:22
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869

[Bug other/35858] time/memory hog for large c++ source.

[rguenth at gcc dot gnu dot org]

--- 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 |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-08 10:04:33
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug middle-end/35861] code bloat due to -finline-small-functions

[rguenth at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861

[Bug tree-optimization/35869] ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization

[ebotcazou at gcc dot gnu dot org]

--- 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=15446&action=view)
Testcase.

To be compiled at -O2 -gnatp for x86 targets.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869

[Bug tree-optimization/35869] New: ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization

[ebotcazou at gcc dot gnu dot org]

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 VECs.
(simplify_switch_using_ranges): New function.  Remove not taken
case labels and edges.
(simplify_stmt_using_ranges): Call it.
(identify_jump_threads): Mark edges we have queued for removal
so we don't thread them.
(execute_vrp): Remove edges queued for removal, update SWITCH_STMT
case label vector.
* tree-cfg.c (group_case_labels): Deal with missing default label.
(tree_verify_flow_info): Allow missing default label.
* stmt.c (emit_case_bit_tests): Deal with NULL default_label.
(emit_case_nodes): Likewise.
(expand_case): Do not rely on the default label to be present.
* expr.c (try_casesi): Deal with NULL default_label.
(do_tablejump): Likewise.

Quick analysis posted at
  http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00558.html


-- 
   Summary: ICE in calc_dfs_tree at -O2 -gnatp after VRP
optimization
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
GCC target triplet: i?86-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869

[Bug c++/35828] ICEs in template-heavy C++0x code

[gcc at cohi dot at]

--- 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
their respective "const static size_t min" members.

In the second example the template structure is recursive, i.e. while trying to
determine seq_min_impl1< ... >::min for some template parameters the compiler
will reach a point where that value, through some steps, depends on itself.

(The meta-programming in the code included is a first step towards eliminating
the recursion.)

In other words: If my current understanding of my code is correct, the ICE from
scheme.ii should be an error message.


-- 

gcc at cohi dot at changed:

   What|Removed |Added

   Severity|blocker |major


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35828

[Bug tree-optimization/35834] building libiberty fails in build2_stat for -mcpu=m32c as of r133403

[rguenth at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=134090
Log:
2008-04-08  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35834
* tree-ssa-address.c (create_mem_ref): Use POINTER_PLUS_EXPR
for adding index to base.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-address.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834

[Bug middle-end/30908] tree cost for types which are > WORD_SIZE

[rguenth at gcc dot gnu dot org]

--- 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

 CC||a dot kaiser at gmx dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908

[Bug target/35867] [4.4 Regression]: gcc.target/i386/addr-sel-1.c

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-04-08 09:39 ---
Heh, see .


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35867

[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[eres at il dot ibm dot com]

--- 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 but 
on targets with limited local store when an overlay technique is used it might
be prefered to place the unwind info in a separate section that will always be
in the memory rather then inlining it using .cfi_* assembler.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999

[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[jakub at gcc dot gnu dot org]

--- 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

[Bug fortran/35870] New: write(*,*), 'teste' does not give error

[leandromartinez dot spam at gmail dot com]

-- 
   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
ReportedBy: leandromartinez dot spam at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35870

[Bug fortran/35871] New: write(*,*), 'teste' does not give error

[leandromartinez dot spam at gmail dot com]

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.


-- 
   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
ReportedBy: leandromartinez dot spam at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35871

[Bug fortran/35871] write(*,*), 'teste' does not give error

[leandromartinez dot spam at gmail dot com]

-- 

leandromartinez dot spam at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |trivial


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35871

[Bug fortran/35870] write(*,*), 'teste' does not give error

[leandromartinez dot spam at gmail dot com]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35870

[Bug fortran/35871] write(*,*), 'teste' does not give error

[burnus at gcc dot gnu dot org]

--- 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 to write standard conforming code, you should instruct the compiler
that you want to do so. Using  -std=f95 or -std=f2003, gfortran prints the
following error message:

write(*,*),  'test'
  1
Error: Extension: Comma before i/o item list at (1)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35871

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[d at domob dot eu]

--- 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 gfortraners read it (and not
> only three Fortraners) and it makes discussing easier than a in a bugreport.

Ok,  sent it in.

> I think it is OK for now, but we need to fix it later. I found a test case
> which crashes gfortran (ICE, internal compiler error) for nested character
> constructors - even without typespec or bounds checks. See PR 35846. I think
> this should be fixed together with the rest.

I thought about possible solutions when introducing my global variable, namely
either to pass them on the argument list down the stack (which is probably what
I would do myself), or to abuse the function stack by saving the old value when
setting and resetting it on return; while this seems a bit hackish to me, it
means probably less changes...  In any case, PR 35846 could be a nice other bug
for me once this one is done ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997

[Bug target/35867] [4.4 Regression]: gcc.target/i386/addr-sel-1.c

[bergner at gcc dot gnu dot org]

--- 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

 AssignedTo|unassigned at gcc dot gnu   |bergner at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-08 06:37:00 |2008-04-08 14:47:27
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35867

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bergner at gcc dot gnu dot org]

--- 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

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[dominiq at lps dot ens dot fr]

--- 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 because the
condition is too broad, as it seems to be the case here. So I think maintainers
should be very careful when they add new "gcc_assert" and monitor the
gcc-testresults mailing list for missing regular testers.

In particular, such modification on powerpc should be correlated to "regress":

regress

2008-04-01 07:19 Results for 4.4.0 20080331 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-01 16:27 Results for 4.4.0 20080401 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-03 13:29 Results for 4.4.0 20080403 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-03 21:27 Results for 4.4.0 20080403 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-04 05:26 Results for 4.4.0 20080403 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-04 13:25 Results for 4.4.0 20080404 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0
2008-04-04 21:23 Results for 4.4.0 20080404 (experimental) (GCC) testsuite on
powerpc-apple-darwin8.5.0

which gives a new result every ~8 hours and has stopped to do so since April
4th (this is why I did a fresh bootstrap in order to know what was going
wrong).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug target/34210] ffs builtin calls undefined __ffshi2

[eric dot weddington at atmel dot com]

--- 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

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34210

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[dominiq at lps dot ens dot fr]

--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864

[Bug target/34916] [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[eric dot weddington at atmel dot com]

--- 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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bonzini at gnu dot org]

--- 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

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[aj at gcc dot gnu dot org]

--- 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

[Bug rtl-optimization/35371] Missing REG_POINTER attribute causes bad indexed load/store operand ordering

[bergner at gcc dot gnu dot org]

--- 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|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35371

[Bug c/35872] New: [4.1 regression] incorrect code for 32bit multiplication by constant

[a dot kaiser at gmx dot net]

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 regression] incorrect code for 32bit multiplication
by constant
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot kaiser at gmx dot net
  GCC host triplet: winavr 20040802
GCC target triplet: avr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug c/35872] [4.1 regression] incorrect code for 32bit multiplication by constant

[a dot kaiser at gmx dot net]

--- 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=15447&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug c/35872] [4.1 regression] incorrect code for 32bit multiplication by constant

[a dot kaiser at gmx dot net]

--- 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=15448&action=view)
assembly output for tiny25


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug c/35872] [4.1 regression] incorrect code for 32bit multiplication by constant

[a dot kaiser at gmx dot net]

--- 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=15449&action=view)
assembly output for mega16


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug fortran/35873] New: problem with gfortran -malign-double

[hjj at ifk dot sdu dot dk]

--> 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
  call getenv("WRKMEM",wrkmem)
  write (0,*)   wrkmem
  read (wrkmem, '(I20)', err=10) lmwrkmem
  write (0,*) lmwrkmem
  stop
   10 continue
  write (0,*) 'err'
  end


-- 
   Summary: problem with gfortran -malign-double
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjj at ifk dot sdu dot dk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug fortran/35873] problem with gfortran -malign-double

[hjj at ifk dot sdu dot dk]

--- 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)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug other/35858] time/memory hog for large c++ source.

[pluto at agmk dot net]

--- 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 package?
Does the non-zero value fix some bugs or sth?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug fortran/35873] problem with gfortran -malign-double

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug target/34916] [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[hutchinsonandy at aim dot com]

--- 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 approval.

Andy



-Original Message-
From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Tue, 8 Apr 2008 11:16 am
Subject: [Bug target/34916] [4.3/4.4 Regression] 
gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os




--- 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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916

[Bug target/35874] New: Error in emit_cmp_and_jump_insn_1, at optabs.c:4425

[mstein dot lists at googlemail dot com]

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 emit_cmp_and_jump_insn_1, at optabs.c:4425
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35874

[Bug target/35874] Error in emit_cmp_and_jump_insn_1, at optabs.c:4425

[mstein dot lists at googlemail dot com]

--- 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=15450&action=view)
from csibe, delta-reduced


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35874

[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class

[jason at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=134099
Log:
PR c++/35734
* class.c (type_has_user_nondefault_constructor): A template
counts as a nondefault constructor.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/ctor1.C
  - copied unchanged from r133987, trunk/gcc/testsuite/g++.dg/warn/ctor1.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/class.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734

[Bug rtl-optimization/35841] [ira] segfault while building libgcc

[mstein dot lists at googlemail dot com]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35841

[Bug target/35872] [4.3 regression] incorrect code for 32bit multiplication by constant

[eric dot weddington at atmel dot com]

--- 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

  Known to work|4.1.2   |4.1.2 4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug target/35872] [4.3 regression] incorrect code for 32bit multiplication by constant

[eric dot weddington at atmel dot com]

--- 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

[Bug rtl-optimization/35875] New: error:

[mstein dot lists at googlemail dot com]

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)
/home/mstein/svn/ira/gcc/testsuite/gcc.c-torture/compile/20011130-2.c: In
function 'foo':
/home/mstein/svn/ira/gcc/testsuite/gcc.c-torture/compile/20011130-2.c:54:
internal compiler error:
in process_bb_node_lives, at ira-lives.c:680

rev: 133990


-- 
   Summary: error:
[ira] Error in process_bb_node_lives, at ira-lives.c:680
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein dot lists at googlemail dot com
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: sparc-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35875

[Bug rtl-optimization/35875] [ira] Error in process_bb_node_lives, at ira-lives.c:680

[mstein dot lists at googlemail dot com]

--- 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

Summary|error:  |[ira] Error in
   |[ira] Error in  |process_bb_node_lives, at
   |process_bb_node_lives, at   |ira-lives.c:680
   |ira-lives.c:680 |[ira] Error in
   ||process_bb_node_lives, at
   ||ira-lives.c:680


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35875

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bergner at gcc dot gnu dot org]

--- 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 this with -O1 (it's ok with -O2 or above) on powerpc{,64}-linux,
during expand, we call swap_commutative_operands_p with a SYMBOL_REF and a REG
which currently prefers the REG first.  Later, break_out_memory_refs forces the
SYMBOL_REF into a register (with the REG_POINTER attribute set), but we're
already done swapping, so we get the wrong operand ordering.  Paolo, I wonder
if this patch instead of the rtlanal.c hunk might be better.  It does fix my
problem:

Index: explow.c
===
--- explow.c(revision 134095)
+++ explow.c(working copy)
@@ -305,7 +305,7 @@ break_out_memory_refs (rtx x)
   rtx op1 = break_out_memory_refs (XEXP (x, 1));

   if (op0 != XEXP (x, 0) || op1 != XEXP (x, 1))
-   x = gen_rtx_fmt_ee (GET_CODE (x), Pmode, op0, op1);
+   x = simplify_gen_binary (GET_CODE (x), Pmode, op0, op1);
 }

   return x;


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690

[Bug fortran/35873] problem with gfortran -malign-double

[hjj at ifk dot sdu dot dk]

--- 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 changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug fortran/35873] problem with gfortran -malign-double

[pinskia at gcc dot gnu dot org]

--- 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 -malign-double and all of libc with
it too.

Please read the documentation more closely since it explicitly says it breaks
compatibility.

See PR 29562, PR 30594, PR 31696 also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bonzini at gnu dot org]

--- 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)
> +++ explow.c(working copy)
> @@ -305,7 +305,7 @@ break_out_memory_refs (rtx x)
>rtx op1 = break_out_memory_refs (XEXP (x, 1));
> 
>if (op0 != XEXP (x, 0) || op1 != XEXP (x, 1))
> -   x = gen_rtx_fmt_ee (GET_CODE (x), Pmode, op0, op1);
> +   x = simplify_gen_binary (GET_CODE (x), Pmode, op0, op1);
>  }

Definitely a good idea.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[jvdelisle at gcc dot gnu dot org]

--- 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

[Bug target/35872] [4.3 regression] incorrect code for 32bit multiplication by constant

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2008-04-08 20:17:37
   date||
   Target Milestone|--- |4.3.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug target/35872] [4.3 regression] incorrect code for 32bit multiplication by constant

[eric dot weddington at atmel dot com]

--- 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|Removed |Added

  BugsThisDependsOn||35519
   Severity|normal  |major
   Priority|P4  |P3
   Target Milestone|4.3.1   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

[Bug c++/35876] New: Exceptions not working on FreeBSD

[yuri at tsoft dot com]

Basic exception example:

#include 
#include 
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 throwing an instance of 'std::string'

Should print:
Caught an exception "String"

Exception is never caught.


-- 
   Summary: Exceptions not working on FreeBSD
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[jaydub66 at gmail dot com]

--- 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 interface for "two" but no actual implementation.


Now, if I apply the fix for PR35830, i.e. adding the following line in
"copy_formal_args":

formal_arg->sym->as = gfc_copy_array_spec (curr_arg->sym->as);

Then also the error message for "call foo(two)" goes away! So this "Type/rank
mismatch in argument 'f'" you saw before was apparently due to that
array-handling bug in "copy_formal_args"!


-- 

jaydub66 at gmail dot com changed:

   What|Removed |Added

 CC||jaydub66 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35877] New: difference between result in optimized and normal executable

[dmarkman at mac dot com]

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, zero)   
nan_inf   = dcmplx(pi/zero, zero/zero)
cmplx_test = nan_inf * normal_number
print *,'nan_inf ',nan_inf
print *,'cmplx_test (inf+iNan)*(2/3+i0) ',cmplx_test
cmplx_test = nan_inf * tth
print *,'tth ',tth
print *,'cmplx_test  (inf+iNan)*(2/3)',cmplx_test
end program

optimized version (gfortran -O test.F)
returns
 nan_inf  (+Infinity,  NaN)
 cmplx_test (inf+iNan)*(2/3+i0)  (+Infinity,   
  NaN)
 tth   0.3 
 cmplx_test  (inf+iNan)*(2/3) (+Infinity, 
NaN)

non optimized version (gfortran test.F)
returns
 nan_inf  (+Infinity,  NaN)
 cmplx_test (inf+iNan)*(2/3+i0)  (  NaN,   
  NaN)
 tth   0.3 
 cmplx_test  (inf+iNan)*(2/3) (  NaN, 
NaN)

Note: gfortran4.2.3 returns for both (optimized/non optimized) NaN, NaN
intel 10 fortran has exactly the same behaviour as gfortran 4.3.0:
optimized Inf,NaN
non optimized Inf,Nan
thanks


-- 
   Summary: difference between result in optimized and normal
executable
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmarkman at mac dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35877

Re: [Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[Andrew Pinski]

Sent from my iPhone

On Apr 8, 2008, at 13:51, "janis at gcc dot gnu dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #6 from janis at gcc dot gnu dot org  2008-04-08  
20:51 ---
My bootstrap on powerpc64-linux worked fine after the fix for 35620  
went in;
see http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00415.html for  
revision
133952.  Since the following day, however, my bootstraps have failed  
building

64-bit libgfortran with an ICE for a libgfortran configure check:

conftest.F: In function 'main':
conftest.F:1: internal compiler error: in  
rs6000_output_function_epilogue, at

config/rs6000/rs6000.c:16855
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:10346: $? = 1
configure: failed program was:
|   program main
| #ifndef __GNUC__
|choke me
| #endif
|
|   end

It also fails for just

 program main
 end

I'm doing a regression hunt to find out what caused that.



No need this is caused by my rs6000 patch.




In the meantime, this has made it more difficult to test the patch  
to fix the

bug I introduced in rs6000_check_sdmode,
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00584.html.  It seems  
like an

obvious fix but it hasn't yet been reviewed.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2008-04-08 21:05 ---
Subject: Re:  [4.4 Regression] Altivec with the vectorizer causes an ICE in
rs6000_check_sdmode



Sent from my iPhone

On Apr 8, 2008, at 13:51, "janis at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #6 from janis at gcc dot gnu dot org  2008-04-08  
> 20:51 ---
> My bootstrap on powerpc64-linux worked fine after the fix for 35620  
> went in;
> see http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00415.html for  
> revision
> 133952.  Since the following day, however, my bootstraps have failed  
> building
> 64-bit libgfortran with an ICE for a libgfortran configure check:
>
> conftest.F: In function 'main':
> conftest.F:1: internal compiler error: in  
> rs6000_output_function_epilogue, at
> config/rs6000/rs6000.c:16855
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> configure:10346: $? = 1
> configure: failed program was:
> |   program main
> | #ifndef __GNUC__
> |choke me
> | #endif
> |
> |   end
>
> It also fails for just
>
>  program main
>  end
>
> I'm doing a regression hunt to find out what caused that.


No need this is caused by my rs6000 patch.

>
>
> In the meantime, this has made it more difficult to test the patch  
> to fix the
> bug I introduced in rs6000_check_sdmode,
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00584.html.  It seems  
> like an
> obvious fix but it hasn't yet been reviewed.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug fortran/35877] difference between result in optimized and normal executable

[dmarkman at mac dot com]

--- Comment #1 from dmarkman at mac dot com  2008-04-08 21:09 ---
I meant
Note: gfortran4.2.3 returns for both (optimized/non optimized) NaN, NaN
intel 10 fortran has exactly the same behaviour as gfortran 4.3.0:
optimized Inf,NaN
non optimized NaN,Nan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35877

Re: [Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[Andrew Pinski]

Sent from my iPhone

On Apr 8, 2008, at 14:05, "pinskia at gmail dot com" <[EMAIL PROTECTED] 
> wrote:





--- Comment #7 from pinskia at gmail dot com  2008-04-08 21:05  
---
Subject: Re:  [4.4 Regression] Altivec with the vectorizer causes an  
ICE in

rs6000_check_sdmode



Sent from my iPhone

On Apr 8, 2008, at 13:51, "janis at gcc dot gnu dot org"
<[EMAIL PROTECTED]

wrote:





--- Comment #6 from janis at gcc dot gnu dot org  2008-04-08
20:51 ---
My bootstrap on powerpc64-linux worked fine after the fix for 35620
went in;
see http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00415.html for
revision
133952.  Since the following day, however, my bootstraps have failed
building
64-bit libgfortran with an ICE for a libgfortran configure check:

conftest.F: In function 'main':
conftest.F:1: internal compiler error: in
rs6000_output_function_epilogue, at
config/rs6000/rs6000.c:16855
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:10346: $? = 1
configure: failed program was:
|   program main
| #ifndef __GNUC__
|choke me
| #endif
|
|   end

It also fails for just

program main
end

I'm doing a regression hunt to find out what caused that.



No need this is caused by my rs6000 patch.


Actually I take that back but it was just fixed by David's fix to  
rs6000.c.









In the meantime, this has made it more difficult to test the patch
to fix the
bug I introduced in rs6000_check_sdmode,
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00584.html.  It seems
like an
obvious fix but it hasn't yet been reviewed.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839




--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2008-04-08 21:10 ---
Subject: Re:  [4.4 Regression] Altivec with the vectorizer causes an ICE in
rs6000_check_sdmode



Sent from my iPhone

On Apr 8, 2008, at 14:05, "pinskia at gmail dot com" <[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #7 from pinskia at gmail dot com  2008-04-08 21:05  
> ---
> Subject: Re:  [4.4 Regression] Altivec with the vectorizer causes an  
> ICE in
> rs6000_check_sdmode
>
>
>
> Sent from my iPhone
>
> On Apr 8, 2008, at 13:51, "janis at gcc dot gnu dot org"
> <[EMAIL PROTECTED]
>> wrote:
>
>>
>>
>> --- Comment #6 from janis at gcc dot gnu dot org  2008-04-08
>> 20:51 ---
>> My bootstrap on powerpc64-linux worked fine after the fix for 35620
>> went in;
>> see http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00415.html for
>> revision
>> 133952.  Since the following day, however, my bootstraps have failed
>> building
>> 64-bit libgfortran with an ICE for a libgfortran configure check:
>>
>> conftest.F: In function 'main':
>> conftest.F:1: internal compiler error: in
>> rs6000_output_function_epilogue, at
>> config/rs6000/rs6000.c:16855
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> configure:10346: $? = 1
>> configure: failed program was:
>> |   program main
>> | #ifndef __GNUC__
>> |choke me
>> | #endif
>> |
>> |   end
>>
>> It also fails for just
>>
>> program main
>> end
>>
>> I'm doing a regression hunt to find out what caused that.
>
>
> No need this is caused by my rs6000 patch.

Actually I take that back but it was just fixed by David's fix to  
rs6000.c.


>
>
>>
>>
>> In the meantime, this has made it more difficult to test the patch
>> to fix the
>> bug I introduced in rs6000_check_sdmode,
>> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00584.html.  It seems
>> like an
>> obvious fix but it hasn't yet been reviewed.
>>
>>
>> -- 
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839
>>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[janis at gcc dot gnu dot org]

--- Comment #9 from janis at gcc dot gnu dot org  2008-04-08 21:18 ---
Subject: Bug 35839

Author: janis
Date: Tue Apr  8 21:17:16 2008
New Revision: 134107

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134107
Log:
PR target/35839
* config/rs6000/rs6000.c (rs6000_check_sdmode): Handle additional
kinds of indirect references.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2008-04-08 20:51 ---
My bootstrap on powerpc64-linux worked fine after the fix for 35620 went in;
see http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00415.html for revision
133952.  Since the following day, however, my bootstraps have failed building
64-bit libgfortran with an ICE for a libgfortran configure check:

conftest.F: In function 'main':
conftest.F:1: internal compiler error: in rs6000_output_function_epilogue, at
config/rs6000/rs6000.c:16855
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:10346: $? = 1
configure: failed program was:
|   program main
| #ifndef __GNUC__
|choke me
| #endif
| 
|   end

It also fails for just

  program main
  end

I'm doing a regression hunt to find out what caused that.

In the meantime, this has made it more difficult to test the patch to fix the
bug I introduced in rs6000_check_sdmode,
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00584.html.  It seems like an
obvious fix but it hasn't yet been reviewed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839

[Bug c++/35878] New: Useless NULL pointer check when constructing object

[ian at airs dot com]

Consider this trivial C++ test case:

#include 
void foo(std::vector* v, int i) { v->push_back(i); }

When I compile this with current trunk with -O2 on i686-pc-linux-gnu I see,
among other things, this:

movl4(%edi), %edx
cmpl8(%edi), %edx
je  .L2
testl   %edx, %edx
je  .L3
movl-4(%edx), %eax
movl%eax, (%edx)
movl4(%edi), %edx
.L3:
leal4(%edx), %eax
movl%eax, 4(%edi)

Note that test for whether %edx is NULL.  That comes from this in the
.004t.gimple file:

  D.7266 = operator new (4, D.7265);
  D.7264 = (int *) D.7266;
  if (D.7264 != 0B)
{
  try
{
  D.7268 = *__val;
  *D.7264 = D.7268;
}
  catch
{
  operator delete (D.7264, D.7265);
}
  iftmp.48 = D.7264;
}
  else
{
  iftmp.48 = D.7264;
}

We get rid of the try/catch pretty quickly, but we never manage to get rid of
the NULL pointer check.

I believe the NULL pointer check is being generated by build_new_1 in cp/init.c
because we are using a type for which TYPE_NOTHROW_P is true.

This NULL pointer check serves no useful purpose.  It is essentially an
abtraction penalty.  We should figure out some way to get rid of it, either in
the C++ frontend, or in some later optimization pass.


-- 
   Summary: Useless NULL pointer check when constructing object
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878

[Bug c++/19476] Missed null checking elimination with new

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-04-08 21:40 
---
*** Bug 35878 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476

[Bug c++/35878] Useless NULL pointer check when constructing object

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-08 21:40 ---


*** This bug has been marked as a duplicate of 19476 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878

[Bug tree-optimization/35833] [4.3 Regression] Wrong code generated with -ftree-vrp

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-08 22:09 ---
Subject: Bug 35833

Author: rguenth
Date: Tue Apr  8 22:07:20 2008
New Revision: 134111

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134111
Log:
2008-04-05  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/35833
* tree-vrp.c (operand_less_p): Deal with non-INTEGER_CST
results from fold_binary_to_constant.
(compare_values_warnv): Likewise.

* gcc.dg/torture/pr35833.c: New testcase.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20080408-1.c
  - copied unchanged from r134108,
trunk/gcc/testsuite/gcc.c-torture/execute/20080408-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/fold-const.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35833

[Bug testsuite/35005] New testcase execute/20071211-1.c assumes 32 bit integers

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #2 from hutchinsonandy at gcc dot gnu dot org  2008-04-08 22:18 
---
Subject: Bug 35005

Author: hutchinsonandy
Date: Tue Apr  8 22:17:52 2008
New Revision: 134114

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134114
Log:
PR target/35005
* execute/20071221-1.c: Adapt test for 16 bit int targets.
* execute/pr35163.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/20071211-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr35163.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35005

[Bug driver/35665] FAIL: gfortran.dg/include_2.f90 -O (test for excess error)

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2008-04-09 00:12 ---
Subject: Bug 35665

Author: danglin
Date: Wed Apr  9 00:11:58 2008
New Revision: 134116

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134116
Log:
PR driver/35665
* collect2.c (write_c_file): Don't wrap in "#ifdef __cplusplus".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/collect2.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35665

[Bug driver/35665] FAIL: gfortran.dg/include_2.f90 -O (test for excess error)

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2008-04-09 00:13 ---
Fixed on trunk.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35665

[Bug fortran/35873] problem with gfortran -malign-double

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-04-09 00:35 
---
If you can separate the I/O functions you need into a separate file and use
-malign-double only for those portions that do computations, you can make this
work.  I can not know from where I sit how important -malign-double is to your
application.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873

[Bug libstdc++/20451] Missing po files in multilib systems

[ghazi at gcc dot gnu dot org]

--- Comment #5 from ghazi at gcc dot gnu dot org  2008-04-09 02:20 ---
Subject: Bug 20451

Author: ghazi
Date: Wed Apr  9 02:19:57 2008
New Revision: 134123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134123
Log:
Backport:
2006-03-24  Mark Mitchell  <[EMAIL PROTECTED]>
Joseph S. Myers  <[EMAIL PROTECTED]>

PR libstdc++/20448
PR libstdc++/20451
* scripts/testsuite_flags.in (--cxxflags): Don't define LOCALEDIR.
* testsuite/lib/libstdc++.exp (libstdc++_init): Always define
LOCALEDIR to ".".
(v3-build_support): Build MO files.


Modified:
branches/gcc-4_1-branch/libstdc++-v3/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/scripts/testsuite_flags.in
branches/gcc-4_1-branch/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20451

[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2008-04-09 02:20 ---
Subject: Bug 20448

Author: ghazi
Date: Wed Apr  9 02:19:57 2008
New Revision: 134123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134123
Log:
Backport:
2006-03-24  Mark Mitchell  <[EMAIL PROTECTED]>
Joseph S. Myers  <[EMAIL PROTECTED]>

PR libstdc++/20448
PR libstdc++/20451
* scripts/testsuite_flags.in (--cxxflags): Don't define LOCALEDIR.
* testsuite/lib/libstdc++.exp (libstdc++_init): Always define
LOCALEDIR to ".".
(v3-build_support): Build MO files.


Modified:
branches/gcc-4_1-branch/libstdc++-v3/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/scripts/testsuite_flags.in
branches/gcc-4_1-branch/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448

[Bug ada/35880] New: GNAT (GCC) Ada does not generate symbolic debug for shared memory

[knoxj at att dot net]

GNAT (GCC) Ada does not generate symbolic debug for shared memory.

'gdb' says
"No definition of "pacs_cp" in current context."

comment "pragma IMPORT" staement and symbolic debug is present.
complete details and step-by-step instructions in README.

I have 'makefile' and short sample source to illustrate problem.


-- 
   Summary: GNAT (GCC) Ada does not generate symbolic debug for
shared memory
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: knoxj at att dot net
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[knoxj at att dot net]

--- Comment #1 from knoxj at att dot net  2008-04-09 02:59 ---
Created an attachment (id=15451)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15451&action=view)
README, makefile, test source files

README has file list description and step-by-step instructions to cause bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[knoxj at att dot net]

--- Comment #2 from knoxj at att dot net  2008-04-09 03:01 ---
README in attachment has file list description and step-by-step instructions to
reproduce bug.


-- 

knoxj at att dot net changed:

   What|Removed |Added

 CC||knoxj at att dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880

[Bug rtl-optimization/35875] [ira] Error in process_bb_node_lives, at ira-lives.c:680

[vmakarov at redhat dot com]

--- Comment #2 from vmakarov at redhat dot com  2008-04-09 03:02 ---
It is fixed by

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00750.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35875

[Bug libstdc++/20451] Missing po files in multilib systems

[ghazi at gcc dot gnu dot org]

-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2
  Known to work||4.1.3 4.2.0
   Target Milestone|4.2.0   |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20451

[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls

[ghazi at gcc dot gnu dot org]

-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org
  Known to fail||4.1.2
  Known to work||4.1.3 4.2.0
   Target Milestone|4.2.0   |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448

[Bug libfortran/35862] [F2003] Implement new rounding modes for run time

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-04-09 05:15 
---
After studying the F2003 standard and our code in output_float, I believe what
gfortran does now is ROUND="compatible".  We round to the nearest and when
there is a tie, we round away from zero.

I think I can manage the other modes.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 05:15:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[charlet at gcc dot gnu dot org]

--- Comment #3 from charlet at gcc dot gnu dot org  2008-04-09 06:45 ---
missing debug info is never really major, since there are always work arounds
(like print statements).

Note that there is close to zero chance that someone will look into your .bz2
file,
let alone your README. Instructions (and test case simplification) should be
part
of the submission of a PR if you want someone to look at it.

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880