[Bug bootstrap/14462] New: a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[Bug bootstrap/14462] New: a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

The following error recently reappeared:

../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  a-calend.adb -o a-calend.o
a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Durat
ion"
a-calend.adb:396:33: warning: "Constraint_Error" will be raised at run time
a-calend.ads:70:33: warning: value not in range of type "Ada.Calendar.Day_Durati
on"
a-calend.ads:70:33: warning: "Constraint_Error" will be raised at run time
make[6]: *** [a-calend.o] Error 1

My last successful build was updated at Mon Mar  1 18:44:21 UTC 2004.

-- 
           Summary: a-calend.adb:396:33: warning: value not in range of type
                    "Ada.Calendar.Day_Duration"
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
                CC: charlet at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
                    dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2004-03-06 18:18 -------
Regression.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|a-calend.adb:396:33:        |[3.5 Regression] a-
                   |warning: value not in range |calend.adb:396:33: warning:
                   |of type                     |value not in range of type
                   |"Ada.Calendar.Day_Duration" |"Ada.Calendar.Day_Duration"


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build, wrong-code
   Target Milestone|---                         |3.5.0


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2004-03-06 20:30 -------
I get a different error if I revert

CVSROOT:        /cvs/gcc
Module name:    gcc
Changes by:     charlet@gcc.gnu.org     2004-03-05 10:58:59

stage2/xgcc -Bstage2/ -B/home/dave/opt/gnu/gcc/gcc-3.5/hppa-linux/bin/ -c -gstab
s -O2      -gnatpg -gnata -I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/ad
a.ads -o ada/ada.o
xgcc: Internal error: Segmentation fault (program gnat1)


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2004-03-07 05:29 -------
I believe the following patch introduced the regression:

2004-03-03  Paolo Bonzini  <bonzini@gnu.org>

        * alias.c (rtx_equal_for_memref_p): Use predicates
        to test rtx classes and new rtx class codes, possibly
        splitting conditionals that tested against '<' and 'o'.
        * caller-save.c (save_call_clobbered_regs): Likewise.
        * combine.c (contains_muldiv, find_split_point, subst,
        combine_simplify_rtx, simplify_if_then_else,
        simplify_set, simplify_logical, expand_compound_operation,
        make_compound_operation, if_then_else_cond, known_cond,
        apply_distributive_law, cached_nonzero_bits,
        cached_num_sign_bit_copies, simplify_shift_const,
        gen_binary, simplify_comparison, update_table_tick,
        record_value_for_reg, get_lsat_value_validate): Likewise.
        * cse.c (mention_regs, find_best_addr, find_comparison_args,
        fold_rtx, cse_insn, invalidate_memory, cse_basic_block):
        Likewise.
        * emit-rtl.c (copy_insn_1): Likewise.
        * expr.c (force_operand): Likewise.
        * final.c (final_scan_insn, get_mem_expr_from_op): Likewise.
        * flow.c (notice_stack_pointer_modification_1,
        invalidate_mems_from_autoinc, ior_reg_cond, not_reg_cond,
        and_reg_cond, elim_reg_cond): Likewise.
        * function.c (update_epilogue_consts): Likewise.
        * genattrtab.c (attr_rtx_1): Likewise.
        * genopinit.c (gen_insn): Likewise.
        * integrate.c (subst_constants): Likewise.
        * jump.c (reversed_comparison_code_parts,
        reversed_comparison_code, delete_related_insns,
        rtx_renumbered_equal_p): Likewise.
        * local-alloc.c (block_alloc): Likewise.
        * loop.c (rtx_equal_for_prefetch_p, maybe_eliminate_biv,
        canonicalize_condition): Likewise.
        * loop-iv.c (simplify_using_conditions, iv_number_of_iterations):
        Likewise.
        * optabs.c (add_equal_node, expand_binop): Likewise.
        * predict.c (estimate_probability): Likewise.
        * ra-debug.c (ra_print_rtx_2op, ra_print_rtx): Likewise.
        * recog.c (validate_replace_rtx_1, comparison_operator,
        offsettable_address_p, constrain_operands): Likewise.
        * reg-stack.c (swap_rtx_condition_1, subst_stack_regs_pat):
        Likewise.
        * regclass.c (scan_one_insn): Likewise.
        * regmove.c (stable_and_no_regs_but_for_p): Likewise.
        * regrename.c (kill_autoinc_value): Likewise.
        * reload.c (find_reusable_reload, find_reloads,
        reg_overlap_mentioned_for_reload_p): Likewise.
        * reload1.c (gen_reload, delete_address_reloads_1): Likewise.
        * rtl.c (copy_rtx): Likewise.
        * rtl.h (CONSTANT_P, INSN_P): Likewise.
        * rtlanal.c (commutative_operand_precedence): Likewise.
        * sched-deps.c (conditions_mutex_p): Likewise.
        * sched-rgn.c (is_cfg_nonregular): Likewise.
        * simplify-rtx.c (simplify_gen_binary,
        simplify_gen_relational, simplify_replace_rtx,
        simplify_unary_operation, simplify_binary_operation,
        simplify_ternary_operation, simplify_rtx): Likewise.
        * unroll.c (reg_dead_after_loop): Likewise.
        * config/alpha/alpha.c (alpha_swapped_comparison_operator,
        print_operand): Likewise.
        * config/arc/arc.c (proper_comparison_operator): Likewise.
        * config/arm/arm.c (arm_arm_address_cost, arm_select_cc_mode):
        Likewise.
        * config/avr/avr.c (_reg_unused_after): Likewise.
        * config/frv/frv.c (frv_ifcvt_modify_tests,
        frv_ifcvt_modify_insn, frv_pack_insn): Likewise.
        * config/i386/i386.c (ix86_comparison_operator,
        ix86_carry_flag_operator, fcmov_comparison_operator,
        arith_or_logical_operator, print_operand,
        ix86_expand_binary_operator, ix86_binary_operator_ok):
        Likewise.
        * config/i386/i386.md: Likewise.
        * config/ia64/ia64.c (not_postinc_memory_operand,
        ia64_print_operand, update_set_flags, errata_emit_nops):
        Likewise.
        * config/ia64/ia64.h (PREFERRED_RELOAD_CLASS,
        CONSTRAINT_OK_FOR_S): Likewise.
        * config/ip2k/ip2k.c (mdr_resequence_xy_yx,
        mdr_try_move_dp_reload, ip2k_check_can_adjust_stack_ref,
        ip2k_xexp_not_uses_reg_for_mem, ip2k_xexp_not_uses_reg_p,
        ip2k_composite_xexp_not_uses_reg_p, ip2k_unary_operator):
        Likewise.
        * config/iq2000/iq2000.c (cmp_op, symbolic_expression_p,
        eqne_comparison_operator, signed_comparison_operator):
        Likewise.
        * config/mips/mips.c (cmp_op, symbolic_expression_p):
        Likewise.
        * config/mmix/mmix (mmix_foldable_comparison_operator,
        mmix_comparison_operator): Likewise.
        * config/pa/pa.c (hppa_legitimize_address): Likewise.
        * config/rs6000/rs6000.c (stmw_operation,
        branch_comparison_operator, trap_comparison_operator,
        ccr_bit): Likewise.
        * config/rs6000/rs6000.h (SELECT_CC_MODE): Likewise.
        * config/s390/s390.c (s390_alc_comparison,
        s390_slb_comparison):L Likewise.
        * config/sh/sh.c (gen_block_redirect, reg_unused_after):
        Likewise.
        * config/sparc/sparc.c (eq_or_neq, normal_comp_operator,
        noov_compare_op, noov_compare64_op, v9_regcmp_op,
        emit_hard_tfmode_operation, reg_unused_after)
        * doc/md.texi, doc/rtl.texi: Likewise.

        * ra-debug.c: Add 2004 to list of copyright years.
        * unroll.c: Likewise.

        * combine.c (simplify_logical): Remove dummy test,
        (apply_distributive_law): Fix typo in comment.
        GET_CODE (x) == AND so x is a commutative binary op.
        * jump.c (delete_related_insns): simplify loop
        condition, move testing of RTX codes inside the loop.
        (rtx_renumbered_equal_p): do not use RTX_CODE.
        * rtl.c (rtx_class): Declare as enum rtx_class.
        * rtl.def (EQ, NE, UNEQ, LTGT, UNORDERED, ORDERED):
        Move to RTX_COMM_COMPARE class.
        (HIGH, SYMBOL_REF, LABEL_REF, CONST, CONST_INT, CONST_DOUBLE):
        Move to RTX_CONST_OBJ class.
        * rtl.h (enum rtx_class): New declaration,
        (RTX_OBJ_MASK, RTX_OBJ_RESULT, RTX_COMPARE_MASK,
        RTX_COMPARE_RESULT, RTX_ARITHMETIC_MASK, RTX_ARITHMETIC_RESULT,
        RTX_BINARY_MASK, RTX_BINARY_RESULT, RTX_COMMUTATIVE_MASK,
        RTX_COMMUTATIVE_RESULT, RTX_NON_COMMUTATIVE_RESULT,
        RTX_EXPR_FIRST, RTX_EXPR_LAST, UNARY_P, BINARY_P,
        ARITHMETIC_P, COMMUTATIVE_ARITHMETIC_P, COMPARISON_P,
        SWAPPABLE_OPERANDS_P, NON_COMMUTATIVE_P, COMMUTATIVE_P,
        OBJECT_P): New macros.
        * config/sparc/sparc.c (noov_compare_op): Remove register
        from parameter.


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-07 06:48 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

Can you please send me a diff of the RTL files before and after my patch?  I
do not build Ada.

BTW, it makes it quite hard to understand the impact of Arnaud's patch until
Ada updates are at least *committed* one by one.  If Ada folks are ok with
sending a bunch of them together, that's fine, but please at least *commit*
them manually.  It will take you longer?  Script it, do whatever you want, but
don't blame people who lose their interest in Ada because of your policies.

Paolo




-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-07 07:17 -------
The change for pa.c looks fine to me, maybe it was somewhere else.  Also I have to agree with Paolo 
about the Ada changes as they make it hard to regtest something.

-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-07 18:26 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> The change for pa.c looks fine to me, maybe it was somewhere else.  Also I have to agree with Paolo 
> about the Ada changes as they make it hard to regtest something.

Paolo's patch introduced the gnat1 segv.  Until we find out what's
causing the segv, I don't think we can say whether there is a problem
with the ada change.  We had an almost "identical" problem a few months
ago caused by an optimization problem.

I don't see a problem with the change to pa.c  I think there was some
change in Paolo's patch beyond the introduction of new macros.

I've looked at the segv a bit.  It's caused by a null value being
returned for a pointer.  I don't see any problem with the code.
The problem would appear to be related to the initialization/setting
of the "struct" that holds the pointer.  I don't know where this
is done.

(gdb) bt
#0  0x001737c0 in system__soft_links__get_sec_stack_addr_nt ()
    at ../../gcc/gcc/ada/s-soflin.adb:232
#1  0x00174500 in system__secondary_stack__ss_mark ()
    at ../../gcc/gcc/ada/s-secsta.adb:462
#2  0x0025dc2c in _ada_gnat1drv () at ../../gcc/gcc/ada/gnat1drv.ads:33
#3  0x004095bc in toplev_main (argc=6065464, argv=0x5c8d38)
    at ../../gcc/gcc/toplev.c:1575

0x001737bc <system__soft_links__get_sec_stack_addr_nt+0>:       addil 25d800,dp,%r1
0x001737c0 <system__soft_links__get_sec_stack_addr_nt+4>:       bv r0(rp)
0x001737c4 <system__soft_links__get_sec_stack_addr_nt+8>:       ldw 57c(,r1),ret0

(gdb) disass 0x001744f4 0x00174514
Dump of assembler code from 0x1744f4 to 0x174514:
0x001744f4 <system__secondary_stack__ss_mark+12>:       ldw 488(,r1),r22
0x001744f8 <system__secondary_stack__ss_mark+16>:       b,l 0x147dcc <osint__file_stamp_hash_table__tab__TtableBIPXb+5576>,r31
0x001744fc <system__secondary_stack__ss_mark+20>:       copy r31,rp
0x00174500 <system__secondary_stack__ss_mark+24>:       ldw -54(,sp),rp
0x00174504 <system__secondary_stack__ss_mark+28>:       ldw 0(,ret0),ret0
0x00174508 <system__secondary_stack__ss_mark+32>:       bv r0(rp)
0x0017450c <system__secondary_stack__ss_mark+36>:       ldo -40(sp),sp
0x00174510 <system__secondary_stack__ss_release+0>:     addil 1800,dp,%r1

The segv is at 0x00174504 following the return from
system__soft_links__get_sec_stack_addr_nt.  The call at 0x001744f8
is an indirect call.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-07 22:02 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

Does it look like miscompilation?

Can you please build a stage1 compiler with a system compiler before and after
my patch, and send the difference in the RTL or assembly?  There should be
none.

Paolo




-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-07 22:39 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

Sorry, I was not clear enough.  What I am asking you is to:

1) build a C/Ada compiler with a checkout prior to my patch, bootstrapping.
Then do "make restage3" but also pass a -d option to the compiler to generate
RTL dumps.

2) build stage1 for a C/Ada compiler with a checkout after my patch, copy cc1
and gnat1 to the stage1 directory of the previous step's build, then do a
"make restage2" there.  Also generate RTL dumps for this build.

Now stage2 is built with optimization with my patch, and stage3 is built with
optimization without my patch.

3) do a "make compare" just to check.  You should get comparison failures,
otherwise something is wrong (probably in this message).

Now for the files that miscompare check which RTL dumps miscompares.  It is ok
if you mail me at paolo.bonzini@polimi.it all the differences between the RTL
dumps (diff -c is ok).

Paolo




-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-08 00:31 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> Does it look like miscompilation?

Don't know.

> Can you please build a stage1 compiler with a system compiler before and after
> my patch, and send the difference in the RTL or assembly?  There should be
> none.

I'll try to work on this tomorrow.  This is a bit tricky as I can't build
gnat1 after your patch.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[charlet at act-europe dot fr]

------- Additional Comments From charlet at act-europe dot fr  2004-03-08 11:40 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> Does it look like miscompilation?

Yes, it does. Clearly this warning should never be generated in 'normal'
conditions by the front-end, and does not on other platforms (this is a
platform independent warning), so the only explanation AFAICS is a
miscompilation.

Also, all Ada changes, including recent ones, are thorougly tested on
several configurations (about 12) using various test suites before being
submitted, so they are always pretty safe (certainly safer than most
other changes which are only tested on one or two platforms typically).

As for committing Ada changes individually, I do not understand why this would
make a difference to you, since each change comes with a separate, complete
entry in the changelog, so could you explain how it would help you to
have the commits performed separately ? Why would it encourage you to
enable Ada and look at Ada failures more than you do now ?

Arno


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-08 18:21 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> As for committing Ada changes individually, I do not understand why this
would
> make a difference to you, since each change comes with a separate, complete
> entry in the changelog, so could you explain how it would help you to
> have the commits performed separately ? Why would it encourage you to
> enable Ada and look at Ada failures more than you do now ?

I would run the binary regression hunter and find which of your changes has
changed the way the compiler is broken.  This may give some clue about which
file is miscompiled.  Now, this time this is not that important, because my
patch did break the compiler, but in the case of latent bugs it would be
better to could track down the exact change that exposed the latent bug.

The only necessary things for me to look at Ada failures (I *am* interested in
them) would be more fine-grained commits and better source-code compatibility
between GNAT releases (why should I compile 3.3 as an intermediate step if my
distro only provides me with 3.2.x?).  Everything else is a plus, but these
two are must-haves.

Paolo




-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[charlet at act-europe dot fr]

------- Additional Comments From charlet at act-europe dot fr  2004-03-08 23:17 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> I would run the binary regression hunter and find which of your changes has
> changed the way the compiler is broken.  This may give some clue about which

Do you mean that the binary regression hunter is not smart enough to
do that ? How does it work ? Can it be improved ? I have no problem
doing semi-manual regression hunting using e.g. dates.

> file is miscompiled.  Now, this time this is not that important, because my
> patch did break the compiler, but in the case of latent bugs it would be
> better to could track down the exact change that exposed the latent bug.

This time, it is completely unimportant and even misleading: Ada bootstrap had
been generally broken for a few days by another change, and fixed by
the change in trans.c, as I explained in my message to gcc-patches,
and as explained in the ChangeLog very clearly.

During the period Ada bootstrap was broken, you committed your change.

So knowing that trans.c is showing the new problem isn't going to help you
at all in this case, since in fact the problem is not 'new' to trans.c, and
would have appeared immediately, had Ada bootstrap not been broken.

Of course, having Ada enabled would have detected both (the general
bootstrap failure and your recent regression) failures early.

> The only necessary things for me to look at Ada failures (I *am* interested in
> them) would be more fine-grained commits and better source-code compatibility

As I said, the ChangeLog are completely fine-grained, so I still don't
understand what added value there would be.

Note that I am trying to understand and be constructive here: if there's
indeed an added value in having more fine-grained commits, then I'd
be willing to investigate it, but I don't see it.

> between GNAT releases (why should I compile 3.3 as an intermediate step if my
> distro only provides me with 3.2.x?).  Everything else is a plus, but these
> two are must-haves.

Actually current GNAT sources are still compatible with GNAT 3.13, we've
made sure of that. The only cases where a version more recent than
GNAT 3.13 is needed is when GNAT 3.13 (or any other version for that
matter) has a codegen bug that makes it unusable on a given target.

Arno


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-09 06:12 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

I can't find any difference in the .o files generated at stage2 with and
without Paulo's patch except for the following two files:

dave@gsyprf11:~/gcc-3.5/objdir/gcc$ for i in ada/*.o;do cmp $i stage2/$i;done
ada/b_gnat1.o stage2/ada/b_gnat1.o differ: char 35, line 1
ada/b_gnatb.o stage2/ada/b_gnatb.o differ: char 35, line 1

These differences are caused by differences in the .c files generated
by gnatbind:

--- ada/b_gnatb.c       2004-03-08 21:13:44.000000000 -0800
+++ stage2/ada/b_gnatb.c        2004-03-08 19:30:32.000000000 -0800
@@ -13,46 +13,6 @@ extern void __gnat_initialize (void);
 extern void __gnat_finalize (void);
 extern void __gnat_install_handler (void);

-extern void system__standard_library___elabs (void);
-extern void ada__exceptions___elabs (void);
-extern void system__exceptions___elabs (void);
-extern void system__soft_links___elabb (void);
-extern void system__secondary_stack___elabb (void);
-extern void system__exception_table___elabb (void);
...

stage1/gnatbind with Paulo's patch generates identical C code to
stage2/gnatbind without Paulo's patch (b_gnatb.c and b_gnat1.c).

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-09 19:11 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

First, the important part: stage2/gnatbind is miscompiled by the stage1 Ada
compiler.  Which of gnatbind's object files (or RTL dumps, even better) are
different?   It should be fairly easy to obtain this information by passing an
appropriate -d option to stage2's make gnattools (both in the tree with my
patch, and without).

Now, more on regression hunting.

> Do you mean that the binary regression hunter is not smart enough to
> do that ? How does it work ?

It works temporally, by doing a binary search on the commits.  It does not
look at each modified file separately because it does not make sense: if I
commit two changes together, most likely separating them will screw up
everything; and if I commit two independent changes, it is supposed that I do
two CVS commits.

What I meant, is that for example I could not understand if the Ada changes
are related; I would have liked to see which of them caused the warning to
appear instead of a SIGSEGV, to help debugging, but the regression tester
treats your Ada update as an unicum, so it cannot help.

Paolo








-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-09 21:30 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

> First, the important part: stage2/gnatbind is miscompiled by the stage1 Ada
> compiler.  Which of gnatbind's object files (or RTL dumps, even better) are
> different?   It should be fairly easy to obtain this information by passing

I didn't actually find any difference in object files.  It seems as if
gnatbind's behavior changed simply because there is some difference in
the object files before and after.  If that's the case, this is probably
an Ada bug.

I need to go back and redo the test as the "-gstabs" option that I had
in BOOT_CFLAGS may have affected the results.  I will also test after
the trans.c change.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-11 23:12 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

> This time, it is completely unimportant and even misleading: Ada bootstrap
> had
> been generally broken for a few days by another change, and fixed by
> the change in trans.c, as I explained in my message to gcc-patches,
> and as explained in the ChangeLog very clearly.
> 
> During the period Ada bootstrap was broken, you committed your change.
> 
> So knowing that trans.c is showing the new problem isn't going to help you
> at all in this case, since in fact the problem is not 'new' to trans.c, and
> would have appeared immediately, had Ada bootstrap not been broken.
> 
> Of course, having Ada enabled would have detected both (the general
> bootstrap failure and your recent regression) failures early.

@#@%#^$#^!  Please don't criticize others.  It just makes people
upset and is not constructive.

1) The ChangeLog entry for trans.c is not written using GCC standards.
Here it is:

2004-03-05  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* trans.c: Reflect GCC changes to fix bootstrap problem.
	Add warning for suspicious aliasing unchecked conversion.

ChangeLog entries are supposed to indicate the functions changed
and what was changed.  They are *not* supposed to contain a justification
for the change.  What the heck does "Reflect GCC changes" mean.  You
would never guess from this log entry that the change contains two
separate and independent changes.

2) One of the changes to trans.c was in fact a fix for the segmentation
fault in gnat1 that I reported in this PR:

@@ -5396,7 +5422,7 @@
 
    /* See if any non-NOTE insns were generated.  */
    for (insn = NEXT_INSN (insn); insn; insn = NEXT_INSN (insn))
-    if (GET_RTX_CLASS (GET_CODE (insn)) == 'i')
+    if (GET_RTX_CLASS (GET_CODE (insn)) == RTX_INSN)
       {
	result = 0;
	break;

3) If this patch had been reviewed, it wouldn't have been accepted.
The above code should be using the INSN_P macro so that that it isn't
dependent on the low level implementation of RTX classes.  The code
wouldn't have broken if it had used INSN_P.  Additionally, the trans.c
change uses whitespace in an inconsistent manner.

3) The change to trans.c did not in fact fix the bootstrap problem.
It had been broken further by this change committed after Paulo's change:

2004-03-04  Jan Hubicka  <jh@suse.cz>

	* cfgcleanup.c (thread_jump): Update call of cselib_init.
	* cselib.c (cselib_record_memory): New static variable.
	(cselib_lookup_mem, cselib_record_set, cselib_record_sets):
	Give up on memories when asked for.
	(cselib_init): Accept new argument.
	* cselib.h (cselib_init): Update prototype.
	* gcse.c (local_cprop_pass): Update call of cselib_init.
	* loop.c (load_mems): Update call of cselib_init.
	* postreload.c (reload_cse_regs_1): Update call of cselib_init.
	* sched-deps.c (sched_analyze): Update call of cselib_init.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[charlet at act-europe dot fr]

------- Additional Comments From charlet at act-europe dot fr  2004-03-12 06:37 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> @#@%#^$#^!  Please don't criticize others.  It just makes people
> upset and is not constructive.

Now you can see how Ada people sometimes feel when this happens the other
way around.

OK, let's be more constructive on all sides.

> 1) The ChangeLog entry for trans.c is not written using GCC standards.
> Here it is:
> 
> 2004-03-05  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
> 
> 	* trans.c: Reflect GCC changes to fix bootstrap problem.
> 	Add warning for suspicious aliasing unchecked conversion.
> 
> ChangeLog entries are supposed to indicate the functions changed
> and what was changed.  They are *not* supposed to contain a justification
> for the change.  What the heck does "Reflect GCC changes" mean.

I agree that this entry is not a wonderful one, although you're not
complaining to the right person.

As for containing justification, that's a fundamental disagreement between
the other GCC modules and the Ada front-end: we, Ada people, consider it
fundamental and much more useful to explain *why* a change is made in
a changelog, since it makes it so much easier to track a change afterwards,
rather than having to dig into the gcc list archives, and this is, when
there *is* a message on a gcc list justifying the change.

We've found that the lack of a justification in changelogs in GCC in general
makes it very hard to track failures and understand changes and is very time
consuming, so we're certainly not willing to loose this very important extra
piece of information.

That's not the right place to discuss this pretty fundamental issue anyway,
but I don't think we're going to change our mind on this issue.

> You would never guess from this log entry that the change contains two
> separate and independent changes.

Then I guess you are not using punctuation like other people do: there
are two sentences in the changelog, clearly separated by a 'dot' and even
a line break. But I see that you are in fighting mode, so I'd rather not
discuss this further.

> 3) The change to trans.c did not in fact fix the bootstrap problem.
> It had been broken further by this change committed after Paulo's change:
>
> 2004-03-04  Jan Hubicka  <jh@suse.cz>

Thanks, that's a constructive hint. Is anyone working on this ?

Arno


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-12 15:46 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

> > 1) The ChangeLog entry for trans.c is not written using GCC standards.
> > Here it is:
> > 
> > 2004-03-05  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
> > 
> > 	* trans.c: Reflect GCC changes to fix bootstrap problem.
> > 	Add warning for suspicious aliasing unchecked conversion.
> > 
> > ChangeLog entries are supposed to indicate the functions changed
> > and what was changed.  They are *not* supposed to contain a justification
> > for the change.  What the heck does "Reflect GCC changes" mean.
> 
> We've found that the lack of a justification in changelogs in GCC in general
> makes it very hard to track failures and understand changes and is very time
> consuming, so we're certainly not willing to loose this very important extra
> piece of information.

Personally, I don't have a strong opinion on this issue as long as the
details of the actual change don't get lost.  In the above, we don't
know which boostrap problem was fixed.  I searched the gcc, gcc-bugs
and gcc-patches for a discussion on a bootstrap problem for Ada and
couldn't find anything.

If the change had said "Use RTX_INSN instead of 'i'", it would have been
immediately clear that what was being fixed was related to Paulo's change.
And as I noted, including a list of the changed functions/macros in the
log entry helps further to narrow the scope of the change.  This detail
is important when problems such as this arise.  Both Paulo and I thought
from your comments and the log entry that there was a second problem
that needed to be addressed.

With Jan's patch reverted, I can sucessfully bootstrap with Ada on
hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.00.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kenner at vlsi1 dot ultra
                   |                            |dot nyu dot edu


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2004-03-13 08:34 -------
Apart from my name being Paolo :-) which I am slowly getting accustomed to, I 
would really want to add that not including function names in ChangeLogs is 
very annoying, especially when you did not change a ton of functions, but a 
single one.  I really do not understand how you can set for such a quest for 
GCC algorithmic documentation and for the GNU coding standards, when you seem 
not to follow your goals for ChangeLogs at least.

Just for comparison, it took me almost an hour to prepare a changelog for my 
RTX class patch, and I am very sorry that I missed the ada directory.  I am now 
fairly positive that it does not cause trouble, but if it will happen six 
months from now, I hope that my changelog will help me and other people find 
the bug.

-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[charlet at act-europe dot fr]

------- Additional Comments From charlet at act-europe dot fr  2004-03-13 12:42 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> Personally, I don't have a strong opinion on this issue as long as the
> details of the actual change don't get lost.  In the above, we don't
> know which boostrap problem was fixed.  I searched the gcc, gcc-bugs
> and gcc-patches for a discussion on a bootstrap problem for Ada and
> couldn't find anything.

I agree that this specific entry lacked details, no doubt about it.
So we're actually both arguing for more details and explanations in
the ChangeLogs :-)

> With Jan's patch reverted, I can sucessfully bootstrap with Ada on
> hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.00.

Is Jan aware of this ? Is he (or someone else) working on addressing
this failure ? If not, could you open a new PR please ? Thanks.

Arno


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-13 16:55 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

> > With Jan's patch reverted, I can sucessfully bootstrap with Ada on
> > hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.00.
> 
> Is Jan aware of this ? Is he (or someone else) working on addressing
> this failure ? If not, could you open a new PR please ? Thanks.

He's on the PR CC list but he could be away.

Why do we need a new PR?  It's Jan's patch that introduced:

../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  a-calend.adb -o a-calend.o
a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"
a-calend.adb:396:33: warning: "Constraint_Error" will be raised at run time
a-calend.ads:70:33: warning: value not in range of type "Ada.Calendar.Day_Duration"
a-calend.ads:70:33: warning: "Constraint_Error" will be raised at run time
make[6]: *** [a-calend.o] Error 1

This was determined by patching trans.c to correct the failure introduced
by Paolo's patch and then doing a search for the patch that introduced the
above failure.

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-03-13 16:56 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warni

> Apart from my name being Paolo :-) which I am slowly getting accustomed to,

Sorry, I seem to want to consistently misspell it :(

Dave


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[charlet at act-europe dot fr]

------- Additional Comments From charlet at act-europe dot fr  2004-03-14 10:08 -------
Subject: Re:  [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

> This was determined by patching trans.c to correct the failure introduced
> by Paolo's patch and then doing a search for the patch that introduced the
> above failure.

OK, sorry for the confusion. There were a little bit too much off topic
discussion on this PR, that I forgot its original subject :-)

Arno


-- 


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

[Bug bootstrap/14462] [3.5 Regression] a-calend.adb:396:33: warning: value not in range of type "Ada.Calendar.Day_Duration"

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2004-04-05 17:02 -------
See <http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00253.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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